Report of the "Reuse and Product Lines" Working Group of WISR8

This report summarizes the discussions held at WISR8 by the Reuse and Product Lines working group. The report synthesizes the discussion, placing treatment of related topics together, as opposed to recording the minutes of the discussion as it occurred.

A product line is a group of related systems which, taken together, address a specific market segment. Product lines are most efficiently built from a common set of reusable assets: domain model, requirements, architecture, software components, test plans, project schedules, tools and environments, etc. A product line built in this way epitomizes reuse in a planned and systematic way.

This working group will explore the issues associated with successful fielding of a product line from a common asset base. We will try to understand the differences between planned, systematic reuse of an asset base over which the developing organization has broad control, and reuse that occurs serendipitously or opportunistically or is based upon assets built by others that may or may not be suitable.

The proposed working group will address practical issues of systematic reuse in a product line context. Actual experience, where available, will take precedence over theoretical supposition. Topics may include (but are not limited to):

Experience reports will be sought. Participants will be asked to choose a small list of topics, which will then be prosecuted to the fullest extent possible under the time constraints.

As a stimulus for discussion, the leader will present a case study in successful product line development (performed by a Swedish defense contractor called CelsiusTech Systems AB). CelsiusTech routinely turns out million-line-plus hard-real-time Ada systems for shipboard command and control for a wide variety of different ships around the world using the product line approach.

Members of the working group included:

The working group leader was Paul Clements of the Software Engineering Institute.

The working group addressed the following issues, each of which will be treated in detail in subsequent sections:

The group tackled the terminological chaos surrounding product lines in short order. We agreed to distinguish between a product line, which is a set of related systems that together address a market segment, and a product family, which is a set of related systems that are built from a common set of core assets. Thus, a product line is a market- or customer-driven concept, whereas a product family is a technology- or implementation-dependent concept.

A product line need not be built as a product family (i.e., from a common set of core assets) although in the context of a reuse conference this type of product line is what we agreed to consider. Conversely, a product family need not be a product line (i.e., addressing a particular market niche).

The similarities of these concepts to domain soon arose. What is the difference between a product line and a domain? One participant maintained that there was no difference, except that domain was a term familiar to developers whereas product line resonated with management, and so the choice of term was audience-dependent. However, borrowing a definition from the Domain Analysis working group, we agreed that a domain was a specialized body of knowledge, an area of expertise. Thus, it is an intangible thing, unlike a product line or product family, each of which is a specific set of actual (or envisioned) products.

Lingering confusion was cleared when we compared product lines and domains. There are:

Further, these terms are dependent upon the context in which they are used, as they are hierarchically recursive. One organization╒s product (e.g., a GUI widget) may be but a single component in the product of an organization building large systems. Either may be built in a product line. Similarly, a product that grew out of a carefully planned product line development (which we referred to variously as a &quote;top-down,&quote; &quote;a priori,&quote; or &quote;planned&quote; product line) could serve as a component in a product line where the components are not designed from scratch but rather found opportunistically (&quote;bottom-up,&quote; &quote;a posteriori,&quote; or &quote;unplanned&quote;).

Paul Clements presented the CelsiusTech case study. CelsiusTech is a Swedish company that builds shipboard command and control systems for many navies around the world. In December of 1985, they landed two major contracts simultaneously. Realizing that they could not possibly complete those contracts one at a time, they adopted a product line strategy as the only way to fulfill their company╒s obligations. Using their extensive domain knowledge born from many years and many products behind them, they produced an architecture that would serve not only these two systems, but future systems that were anticipated. Today, CelsiusTech has fielded over 55 variations of their basic system on several different classes of ships, including submarines. A typical system has 15-30 nodes on a local area network, 30-70 CPUs, and 100-300 separate Ada programs of 1-1.5 million lines of Ada code. Their architecture is a carefully layered one, with application-dependent, machine-independent software at the top and application-independent, machine-dependent software at the bottom. Strict and careful attention was paid to design principles of abstraction, encapsulation, and information-hiding. The components that are reused from product to product are large-scale pre-integrated chunks called system functions, which are user-visible features of the systems, and this large-grained reuse was a key to their success. CelsiusTech reports around 80% verbatim reuse from system to system, delivery times an order of magnitude less than before, and whole systems integrated by one or two people. Today they field systems in their product line using a work force about a third the size of a few years ago, and report greater reliability, predictability, and customer satisfaction. One of the effects of product line development for CelsiusTech has been a different customer interaction model. Customer requirements are now negotiated with the core asset group (to make sure the proposed system does not radically depart from the product line); customers have formed a user group to jointly drive their requirements evolution.

Jeff Poulin presented an organization for a management information system product line at Lockheed Martin. It resembled the CelsiusTech organization in that there was a group responsible for maintaining the reusable assets, and this group is separate from the groups responsible for fielding individual products. Overseeing both the reusable asset group and the product groups is an architect with the authority to keep the products conforming to the architecture, and responsible for evolving the architecture to respond to change. A separate group is responsible for configuration management, maintaining a small number of versions of each of the assets. Figure 1 illustrates. Jeff reported around 20% reuse, which is quite high for MIS systems.

Ernesto Guerrieri explained his company╒s approach to product lines is to deliver product &quote;kits&quote; to customers. The domain is software for institutions of higher education: student information systems, alumni development, financial management, and human resources. A kit includes all of the documentation and configurable software with which a customer can product a product to satisfy his particular requirements. Domain analysis forms an explicit front end to the process of producing the kits (which is equivalent to defining the product lines). The early or &quote;premier&quote; customers got to participate in the domain analysis effort, thus assuring applicability to their particular needs, in return for being the company╒s &quote;early adopters.&quote; Using this product line approach, the company╒s customers can get a system delivered to them within about a month.

Cornelia Boldyreff and Oh-Cheon Kwon presented a process model for configuration management in a product line environment.

From these four presentations, some important themes emerged:

Other themes also emerged, such as the key role of architecture, which will be discussed in the following sections.

Different organizations will take different paths towards successful development and deployment (marketing) of a product line. The group spent time trying to enumerate what the discriminating factors were that would affect an organization╒s approach or chances of success. These factors are related to the organization itself, and the world in which it finds itself (such as the nature of its products and its market).

About the product, what it does, and how it is built:

About the product╒s domain:

About the marketplace:

Risks associated with product line development identified by the group include:

A product line cannot exist without an architecture. Usually the architecture is explicitly designed for the product line. It is possible that the architecture for a single product will be general enough to support all future (less general) versions of the system, but this is highly unlikely.

The architecture forms the basis for product line evolution, for growing (as opposed to building) software [Brooks 87]. It is an expression of the commonality across products assumed by the product line designer(s). It is also at the very least a de facto expression of the variability that the product line encompasses. Every architecture divides all changes into three classes: (a) changes that are confined to a single component; (b) changes that affect several components; and (c) changes that affect the architectural underpinnings. Hence, an architecture that is successful in the context of a product line is one in which the variation across the products falls into the first or second class. Further, an architecture should make it so that the cost of a change (producing a variant) is proportional to the value of making that change as well as the likelihood that the change (variant) will be required.

In addition to the standard notion of an architect responsible for the overall structuring of the system, its parts, and their interaction and coordination, there are also domain architects. These are experts in particular domains, such as security or networking, who may be called in to provide solutions to particular problems. Hence, the overall architecture should accommodate the work of these experts by providing them well-encapsulated sections of the system in which to apply their solutions.

Architectures are often represented by system views, reflecting the different structures that are present in every system. These different structures and the views that show them provide opportunities for managing different aspects of a system╒s quality attributes such as performance or modifiability. Views most often used include:

Performance is most affected by the process and physical views; modifiability is usually the purview of the modular view; correctness often resides in the functional and process views.

How might each view change in a product line context, as opposed to a single-system development? If some products were proper subsets of others, that subsetting might be accomplished by eliminating processes and/or modules and/or functions, impacting all affected views. Some versions might run on different hardware configurations, affecting the physical view.

Ownership of the architecture is a key issue. Ownership means controlling how it evolves over time, as well as making sure that &quote;architectural drift&quote; does not occur╤this is when individual projects make unauthorized changes to the reusable components or how they interact with each other.

This implies the importance of having a central architectural authority to hold tightly to the reins of the product line. But in very large systems, it is unlikely that a single person can perform all of the duties, attend all of the meetings, keep abreast of all anticipated changes, perform all of the enforcement, and maintain all of the designs that are necessary to sustain a product line throughout its life. Hence, a hierarchical arrangement is the norm, where there is a chief architect who retains authority, but who has a staff that helps promulgate policy and brings important matters to his or her attention. Here, the architect can help his or her own plight by making sure that the architecture is cleanly divided into well-defined components with well-specified interfaces. Issues brought to the architect╒s attention will often be couched in terms of those interfaces; hence, the software-to-software interfaces are also the backbone of the team-to-team or architect-to-component interfaces as well.

Configuration management and version control are key issues and must be addressed carefully and rigorously in order for the product line to succeed. A corollary issue is that it is important to decide how many versions of reusable components are going to be maintained and supported. CM is more complicated in a product line context; for two reasons: (1) a change must be considered not from the point of view of a single product, but in terms of keeping the changed component usable by all of the products that currently employ it; and (2) it is more likely to be necessary to maintain separate versions of reusable components, as opposed to simply supplying the most recent one, as may suffice in one-at-a-time development.

Strong, centralized architectural control is key to product line development, but also management of change and evolution. In conventional development, the architect answers to a single customer or set of customers, and their needs are often paramount. But in a product line, the architect answers to users of all versions of the system, and changes to accommodate a single user╒s needs are less imperative than keeping the product line intact.

Variation in the reusable assets is often handled by parameterization. However, this approach carries its own problems. New combinations of parameters produce effectively new versions of the code that must be tested. However, regression testing tools do not know the different between a parameter whose new value makes a difference and one that doesn╒t, and testing is sometimes over-done. Further, some combinations of parameters may be illegal, and these must be identified and ruled out. This is analogous to the feature interaction problem in telecommunications.

What happens when a request for a variant is outside the boundaries of the product line? Rejection or renegotiation of the request is certainly a possibility, but often this is not the desirable response. Impact analysis can be done to gauge the extent (and cost) of the change. As noted in the previous section, the product line architecture will determine how hard it will be to make the required modification(s). A business analysis can be done to determine the value of the new variant, perhaps in the context of anticipated market shifts where the variant might be of value beyond the specific customer who requested it. Then, as before, the cost and value can be compared. Thus, the concept of &quote;outside the product line&quote; really is a phrase without operational meaning. Ease of change is spectrum, not a boolean. The required change(s) will be quite easy (e.g., via parameterization that is already in-place), somewhat hard (e.g., a component will have to be replaced), or very hard (e.g., the entire architecture must change).

When a new product is requested, who is responsible for providing it? An individual product manager may well be the one who gets the request, from his current customer. It may be to his advantage to let the reuse group handle the request, because it will cost him less; however, it may take longer that way, thus alienating his customer. The answer to this question may well depend on two things: (a) What part of the organization fields the new request? Does a product manager, or is there a product-line-level clearinghouse for such requests? This is a customer management issue. (b) How large-grained is the reuse in the product line? Products with 10% reuse may be more likely to handle changes themselves, as opposed to projects with 80% reuse consisting mainly of a few very large reusable chunks.

The ability to accommodate variation was the primary difference we conjectured as existing between pure-hardware product lines and software product lines. Software is more variable, and its variations can be bound much later (even at run-time) than typically can be done with hardware.

We did not, of course, address every relevant topic to complete depth. This section records those issues that we touched on only briefly. They included:

Intellectual control seems to be a key to successfully developing a product line. An organization must achieve intellectual control over the domain(s) involved, as well as over its goals, plans, assets, and capabilities. Product lines strongly resemble conventional system building in many ways, especially when building a system with changeability in mind, and especially when building a system using reusable assets. However, there are important differences having to do with process, organizational structure, customer interfaces, and technical issues. An organization must be aware of the key issues if it hopes to successfully develop a product line and enjoy its considerable benefits.