IDI - Software Product Lines

Developing a family of software intensive products brings challenges which are distinct from single-product development. In a family of similar products, much functionality is similar across products in the product line. If a certain feature is used in one product, customers expect that feature to work the same way in other products.

A Tale of Two Managers
Some years ago a very bright and enterprising young manager noticed that several of his people were doing essentially the same work. It occurred to him that instead of having 5 different engineers independently designing the same feature, perhaps it would be smart to develop the feature once and then just use it in 5 different products. Should be cheaper to develop since you're only doing it once, and all the products in the product line will automatically work the same since they are using the exact same design. The manager was promoted for his ingenuity.

Things were going along well until one day ... more

Remember the last time you drove a Honda when you're accustomed to driving your Audi? Remember how long it took to figure out how to get that Cruise Control to work? Sure, Cruise Control seems simple enough, but the Honda uses an extra "on / off" switch which the Audi doesn't use, and they put the buttons on the steering wheel. I can accept such differences between a Honda and an Audi -- but I sure want my rental Audi to work the same as my own!

Companies which develop product lines understand this issue. Customers want the features to behave the same, and so do the engineers. So what's the problem, then? Just make them the same, right?

Here's the problem: the Audi A4 engineering team has different engineers on it than the Audi A6 team. Different engineering teams design the Honda Accord from those that design the Honda Civic. It takes work to make them the same; it doesn't just happen. And then there's the fact that many features in most products are a lot more complicated than Cruise Control - not to mention that under the hood even Cruise Control can be rather complicated. If you have 20 products in your product line, made by 20 different engineering teams, and the features are complicated, then it takes real diligence to make them behave identically.

The software engineering research community has been looking at this problem for some 10 years now. We've reached some simple but compelling observations:

The Software Product Line Conferences (SPLC) in the USA and the Product Family Engineering Conferences in Europe have been the primary vehicles for disseminating research and experience results. Also the Software Engineering Institute of Carnegie-Mellon University has become the best resource for information and methods in software product lines. Over time, a wealth of information has been compiled about issues, pitfalls, and best practices in moving toward a high degree of reuse in software.

A Software Product Line is way of generating software and related products from reusable Core Assets, based on a Product Configuration. An automation process constructs the final products and documentation by transforming the Core Assets as dictated by the Product Configuration. This concept is illustrated in the diagram below.

Every modern software development system uses a process of this sort. In the simplest example the Production System is a programming language compiler, and the Product Configuration is a "makefile". The compiler transforms the software source files into executable software using the makefile as a guide.

The Software Product Line methodology formalizes this essential framework, taking explicit account of the differences between products in the product line by defining Variation Points. A Variation Point is essentially a question which distinguishes one product from another. (E.g. "is the product green or blue?" or "how many simultaneous network connections are supported?"). A Product Configuration is the answer to all such questions, yielding a complete specification of the product.

Capabilities (c) and (d) taken together are called a Software Component Framework. There is no single Component Framework which is suitable for all applications. There are some off the shelf component frameworks for business and desktop applications (e.g. Microsoft COM, Microsoft .NET, JavaBeans, and Enterprise Java Beans). For most embedded systems, however, no suitable Component Frameworks are commercially available.

The earliest and simplest Software Product Lines typically focus on building executable software from software components, but do not address issues of requirements management or documentation. Similarly, the earliest and simplest Production System mechanisms for transforming software components into executable systems used simple "IFDEFS" and custom build scripts. Over time the industry has discovered that these simple mechanisms, though effective when the number of Variation Points is small, do not scale well when the number of Variation Points and / or number of Products grows large.

The Product Line Studio^TM suite of tools includes a full-featured implementation of capabilities (a) and (b) and tools to build capabilities (c) and (d) that are customized to your product line.

Product Line Studio^TM delivers scalable reuse based on formal methods for managing Variation Points and for managing the transformation of Core Assets into executable products and documentation. And it provides all the primitives needed to make high-performing Transformation Engines perfectly tailored to custom Software Component Frameworks.

Product Line Studio supports processes of all process scalability levels (Note: read about the Software Product Line Process Scalability Model), and gives a clear upgrade path for companies requiring a low process scalability now, but needing to transition to a highly scalable process at some point in the future.

Integrated Dynamics, Inc. (IDI) has been involved for years behind the scenes developing large product lines inside large companies. Product Line Studio (PLS) brings the embodiment of the best practices we've found over the years to companies embracing the elements of Software Product Lines. Product Line Studio is a toolkit of modules and associated best practices. It enables our clients to quickly apply best practices to their software product lines. For clients needing optimized and tailored solutions, PLS also enables clients to extend and integrate for their unique product line needs, more quickly and at a small fraction of the cost of building a tool from scratch. The result keeps our clients focused on their products rather than on building infrastructure tools, making them more productive faster, and avoiding pitfalls along the way.