A Framework for Software Product Line Practice, Version 5.0
All Three Together
Each of the three activities (core asset development, product development, and management) is individually essential, and their careful blending is also essential-a blend of technology and business practices. Different organizations may take different paths through the three activities. The path they take is a manifestation of their production strategy, as described in Core Asset Development. Product line practice patterns [Clements 2002c], especially the SEI Adoption Factory pattern [Northrop 2004a], are a way to help organizations chart their own path through the activities.
Many organizations begin a software product line by developing the core assets first. These organizations take a proactive approach [Krueger 2001a]. They define their product line scope to define the set (more often, a space) of systems that will constitute their product line. This scope definition provides a kind of mission statement for designing the product line architecture, components, and other core assets with the right built-in variation points to cover the scope. Producing any product within that scope becomes a matter of exercising the variation points of the components and architecturethat is, configuring the components and architectureand then assembling and testing the system. Other organizations begin with one or a small number of products they already have and then use them to generate the product line core assets and future products. This approach is reactive.
Both of these approaches may be attacked incrementally. For example, a proactive approach may begin with the production of only the most important core assets, rather than all of them. Early products use those core assets. Subsequent products are built using more core assets as they are added to the collection. Eventually, the full core asset base is fielded; earlier products may or may not be reengineered to use the full collection. An incremental reactive approach works similarly; the core asset base is populated sparsely at first, using existing products as the source. More core assets are added as time and resources permit.
The proactive approach has obvious advantagesproducts come to market extremely quickly with a minimum of code writing. But there are also disadvantages. It requires a significant up-front investment to produce the architecture and the components that are generic (and reliable) across the entire product space. And it also requires copious up-front predictive knowledgesomething that is not always available. In organizations that have long been developing products in a particular application domain, that is not a tremendous disadvantage. For a green field effort, where there is no experience or existing products, that is an enormous risk.
The reactive approach has the advantage of a much lower cost of entry to software product lines because the core asset base is not built up front. However, for the product line to be successful, the architecture and other core assets must be robust, extensible, and appropriate to future product line needs. If the core assets are not built beyond the ability to satisfy the specific set of products already in the works, extending them for future products may prove too costly.
Whatever the approach, the process is rarely, if ever, linear. The creation of products may have a strong feedback effect on the product line scope, the core assets, the production plan, and even the requirements for specific products. The ability to turn out a particular member of the product line quicklyperhaps a member that was not originally envisioned by the people responsible for defining the scopewill, in turn, affect the product line scope definition. Each new product may have similarities with other products that can be exploited by creating new core assets. As more products enter the field, efficiencies of production may dictate new system-generation procedures, causing the production plan to be reworked.