Software Product Lines
Framework Home
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Technical Management
Practice Areas
Configuration Management
Make/Buy/Mine/Commission Analysis
Measurement and Tracking
Process Discipline
Technical Planning
Technical Risk Management
Tool Support
Organizational Management
Practice Areas
Frequently Asked Questions

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

Tool Support

Software development organizations use tools to support many of the activities necessary to transform a set of customer needs into a useful product. A multitude of computer-aided software engineering (CASE) tools are available to help automate the analysis, design, implementation, and maintenance of software-intensive products. The challenge is to choose and use tools wisely to support the business goals of the organization and the technical needs of the product developers.

Typically, many tools are used over the life of the project. The degree to which they interoperate and support the development process can have a large effect on the productivity of the development team and the quality of the resultant products [Bruckhaus 1996a, Low 1999a]. Standards have emerged to provide guidance in the evaluation, selection, and adoption of CASE tools [IEEE 1998a, IEEE 1996a, ISO 1995a], and several authors have described approaches to the tool integration problem and the results of tool adoption studies [Brown 1994a, Brown 1994b, Bruckhaus 1996a, Budgen 2003a, Favre 2003a, Jansen 2004a, Low 1999a, Maccari 2000a, Powell 1996a, Vollman 1994a].

Aspects Peculiar to Product Lines

If you're building a software product line, a variety of tools will likely be used, since there is no single tool that addresses the needs of all product line practices. While many of the practices supported by tools are applicable to product lines, the product line context brings some of its own particular needs and risks of its own.

This practice area does not address the related issue of choosing and using technologies (such as distributed object technology) that may be new to a product line organization and for which tool support may be required. The focus here is on applying familiar tools to practices in a product line context.

The critical aspect of this practice area is support for concurrently creating, maintaining, and using multiple versions of product line artifacts–both core assets and products. That support requires a development environment that facilitates the coordination of core asset development and product development teams and processes and the sharing of core assets among teams.

Tool support for a product line is therefore more than the sum of the capabilities of individual tools that support specific software engineering activities. The interoperability of a chosen set of tools is critical for the automated production of products in a product line from core assets. An integrated product line support environment will

Together, these items represent a vision of an integrated product line tool environment. Although we can expect reality to fall somewhat short of this vision, remembering the ideal helps us nudge the real environment in that direction. Jansen and Bosch, for example, examined the issue of tool support for architectural evolution [Jansen 2004a]. They rated five tools against the requirements needed to support architectural design decisions and, not surprisingly, found plenty of variation in the results. Their conclusion was that architectural tool support does not view evolution as an inherent part and distinct dimension of software architecture.

Establishing tool support for a product line involves the following activities:

Application to Core Asset Development

Tool support for core asset development focuses on the commonality and variability of the core assets from which product line instances will be created. An ideal tool set for core asset development supports the development of both core assets and mechanisms for using them to construct products.

Tools are needed for developing all sorts of core assets, including those for constructing documents, code, test support, and installation–in other words, those that support adopted product line practices. For example

Application to Product Development

The exact role of tool support in product development depends on the degree of automation that has been decided on during core asset development and production planning. The development of products may be partially or wholly automated; in the extreme, the products may actually be generated by tools that are created specifically for the product line. In that case, tool support is extensive; the software engineering environment is a production constraint that must be factored into the architecture design and component development for product developers, and it is a significant element of the production plan.

The means of product development are specified in the product line's production plan. Tool support for product development is a particularly important part of that specification because the chosen practices and tools must be compatible. The nature of the production plan can differ substantially depending on the degree to which product development activities are to be automated [Chastek 2002b, Chastek 2002c].

Example Practices

Current tool support for product lines is based on a variety of tools used in the software engineering activities of conventional development efforts and then "stretched" to accommodate product lines [Bass 2000a]. Using these tools successfully in a product line context requires practices that emphasize the tools' fitness of purpose (both individually and collectively), the quality of the software produced using them, their effect on the product line development process, and the business benefits of using them. If an organization's workforce is geographically distributed, tool selection and enforcement must be an early consideration.

The practices discussed below are all based on established practices for CASE tool support and adapted to the product line context.

Identification of needs: In addition to tools that directly support software development, product line tool support is essential for CM, planning, and all types of documentation. All of these activities are good places to begin identifying specific needs.

Selection: Bass and colleagues provide a comprehensive checklist of tool selection criteria for software product lines [Bass 2000a]. Example criteria include tool features, cost, vendor stability, training, interoperability with other tools, and process implications. Powell and colleagues describe an evaluation process that generates selection criteria from a checklist of issues [Powell 1996a], and the longest section of the International Organization for Standardization (ISO) standard 14102 [ISO 1995a] deals with the characteristics by which tools can be selected and evaluated. Other practitioners advocate tying the selection and integration of tools to the development process to be used [Brown 1994a].

Evaluation: Brown advocates an evaluation approach based on the desired quality attributes of the entire tool support environment, not just the individual tools [Brown 1994b], and Garlan, Allen, and Ockerbloom describe integration woes that have particular relevance for product lines [Garlan 1995a]. The evaluation process described by Powell and colleagues [Powell 1996a] and the Institute of Electrical and Electronics Engineers (IEEE) standard 1348-1995 [IEEE 1996a] include guidelines for the pilot use of a tool. Favre and colleagues observed that even when tools are quite close to solutions and based on well-defined concepts, there are still many important barriers to adoption; those authors list a range of issues from usability and customization to evolution and organizational strategy [Favre 2003a].

Automation: Automated derivation of products requires an explicit tool chain that begins with domain concepts and ends with executable code [McGregor 2005b]. There are several paths between these two end points, and the tools are somewhat different along each one. Basically, automated derivation is based on some type of modeling language that is specific enough to have a well-defined semantics yet at a high enough level to allow direct involvement of customers. McGregor lists five main approaches to automatic derivation:

  1. Specification-Based
  2. Intelligent Build
  3. Domain-Specific Languages (DSLs) and Product Generation
  4. Metamodeling
  5. Frame Technology

These approaches are not at the same level of abstraction, and they are not mutually exclusive. Each one requires tool support. Consider two examples that differ in the grain size of the units of derivation:

Both domain-specific languages and frame technologies are based on the use of metamodeling techniques. Metamodels provide layers of abstraction that hide the complex mechanisms of execution behind the familiar concepts of a domain. The metamodels provide a foundation on which tools can be based, allowing new tools to be developed and deployed quickly.

Practice Risks

Tool support makes some tasks more convenient and others (such as extensive unit testing or CM) practical where they otherwise would not be. Inadequate or inappropriate tool support has a devastating effect on productivity in all parts of a project where tooling could be applied. Specific tool support risks include the following [Bass 2000a]:

Further Reading

Both the IEEE and ISO have issued comprehensive standards for CASE tool selection, evaluation, and adoption.

[IEEE 1996a]
The IEEE standard views CASE tool adoption as more than just the selection of CASE tools; adoption requires the planning and implementation of an entire set of technical, organizational, cultural, and management processes to achieve desired improvements in software development. In addition to the steps for defining CASE needs and evaluating and selecting CASE tools, the practice also includes guidance for conducting a pilot and fostering the routine use of adopted tools. Annexes to the standards provide additional information on aspects of the practice, including defining the: organizational CASE goals, needs, and expectations; approaches to developing an adoption strategy; and evaluation criteria for a pilot.

[ISO 1995a]
The ISO standard provides guidance on identifying organizational requirements for CASE tools and mapping those requirements to the characteristics of candidate tools to be evaluated. It also describes a process for selecting the most appropriate tool from a candidate set based on the measurements of the defined characteristics. An appendix discusses the advantages and disadvantages of three kinds of selection algorithms. (The ISO standard ISO/IEC 14102 has been adopted by the IEEE as IEEE Std.1462-1998 [IEEE 1998a].)

[Bass 2000a]
Bass and colleagues report on what a group of product line practitioners had to say about tool support for product lines.

[Krueger 2002a]
Kruger situates the problem of variation management for a software product line in the context of a multidimensional CM problem and describes a tool called Gears built specifically for software product lines.

[Lundell 2004a]
Lundell and Lings survey the historical roots of the factors contributing to the tension between user expectations of CASE technology and the actual products in the marketplace.

[McGregor 2005b]
McGregor surveys automatic derivation techniques for product lines, including the related technologies, assumptions, and approaches.

[Ossher 2000a]
Ossher and colleagues present a roadmap of software engineering tools and environments based on their personal view of the key issues, themes, and future challenges.

Industry evaluations: The Ovum company ( produces periodic, comprehensive evaluations of software engineering technologies. The company evaluated software CM tools in April 2005 and software testing tools in December 2005 and January 2006.

Open source resources: Eclipse ( is an open source community whose projects focus on providing an extensible development platform and application frameworks for building software. The Eclipse Platform is designed for building integrated development environments (IDEs); subsets of the platform can also be used to build arbitrary applications. Another open source community effort, NetBeans (, provides an IDE and a NetBeans Platform.

Next Section Table of Contents Previous Section