Product Lines

As companies search for techniques that will provide leverage in the manufacture of software, the product line approach has allowed some to achieve remarkable increases in productivity [Dono00]. The Software Engineering Institute (SEI) is pursuing an initiative in this area and has published much good information on this topic [NoCl00]. These gains are achieved by a three-pronged approach: an organizational strategy, technical management tactics, and software engineering methods. We will discuss each of these, but we will focus on the software engineering level.

Before we do that we need to define a few concepts. A software product line is a set of software products that are sufficiently closely related that they can be constructed from a common set of pieces. If this sounds like yet another attempt at reuse, you are correct. However, this is the most comprehensive approach we have seen to date and the most successful. It starts at the organizational level where a set of products is defined. During product definition, a set of variation points, which roughly correspond to hot spots of a framework, is identified. These are the areas of functionality that will vary from product to product within the product line.

The product line approach uses what is referred to as a set of core assets to build the individual products. The most important asset of the product line group is the product line architecture. This architecture provides the skeleton onto which components are attached to form an application. The architecture description identifies the points at which variations are allowed. The architecture also specifies a set of attributes that the product is expected to achieve. These attributes include performance goals, security features and expectations for extensibility.

The companies that can most productively utilize a product line approach are those that have moved above Level 1, as defined in the Capability Maturity Model for Software (SW-CMM)^[1] [SEI93]. This approach involves the coordination of processes across a set of product development teams and between the product line level and the level of individual products. It also involves a sophisticated planning process that builds a base of collected data and makes information-guided decisions.

^[1] Capability Maturity Models is a registered trademark of the SEI. The SEI has defined the CMM as a scale against which the process maturity of an organization is measured. The scale defines five levels with Level 1 being the least mature.

Testing at the Organizational Management Level

A company that adopts the product line approach organizes its resources to support the flow of information and assets among multiple product development efforts. For our purposes, the testing assets at this level include a product line test strategy and a master test plan. The test plan defines an organization of the groups who will be responsible for various types of testing. The goal of that organization is to achieve the same reuse in testing that will be realized in development.

Testing at the Technical Management Level

A product line organization makes tactical decisions about the methods by which they will implement the organizational strategy. This includes determining the levels of test coverage needed to achieve the desired level of quality and techniques for organizing test software and test cases. It also includes defining a test process that is integrated with the software development process.

Testing at the Software Engineering Level

A product line organization implements the tactical decisions in two groups: a product line development group that manufactures the core assets and the individual product teams that build upon the core assets. The product line group produces a product framework and a set of components that can be composed within the framework. The individual product teams produce additional components needed for specific products; however, these components are only introduced at the previously identified points of variation. After mapping the techniques described in previous chapters, you will find that the responsibilities for testing are assigned as shown in Figure 10.9.

Figure 10.9. Testing responsibilities in a product line project

Testing in a Product Line Project

The basic testing process in a product line project is very similar to the process that we have described in this text. The test assets are originated by the product line development team and are designed so that they are reusable across the multiple product development projects. The organizational structure exists to facilitate this approach by establishing planning, reporting, and supporting lines of communication and software delivery within the product line organization.

The product line architecture is thoroughly verified using the guided inspection technique. The architecture is inspected for qualities beyond the standard complete, correct, and consistent. Depending on the domain, the architecture may be evaluated for such qualities as performance and security. In Chapter 4, we presented techniques for inspecting architectures. Using executable representations such as Rapide or using tools such as ObjectTime, working models of the architecture are created, inspected, and finally used as the basis for implementation. The product line architecture will be used for several products, so it is cost effective to spend adequate resources to inspect the architecture thoroughly.

At the points of variation in particular, the architecture will define interfaces that specify the services expected at that point. The product line team can define a standard set of test cases based on that interface. The product line team creates the basic PACT classes for the components produced at that level. When a product team produces a substitute component for a new variation, it is responsible for creating a new PACT class from the existing base classes.

Although product validation is the responsibility of the individual product teams, the product line team provides important inputs into the process. The specific requirements for a product developed in the product line are derived from the base requirements developed at the product line level. Even at the GUI level of testing, it is possible to utilize the hierarchical organization of the product line project.

The scripting languages of some of the GUI-level test tools provide for inheritance between test scripts. We have built specialization hierarchies of test scripts for execution by a GUI-based test tool using the scripting language in that tool. The more general levels in the hierarchy can be shared among many product teams who create the lower levels of the hierarchy specific to their individual product. We have also used this technique to parallel the extends relationship between use cases.

Future

The product line approach is a relatively recent step in the evolution of software manufacturing. It is our hope that the heavy emphasis on process in this type of approach will result in an emphasis on early measures such as guided inspection. This, combined with an efficient means of maintaining test suites, can result in high-quality software.