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

Technical Planning

Planning is one of the fundamental functions of management at any level. It provides the basis for the other management functions, particularly tracking and controlling. This practice area is concerned with the planning of projects. By project, we mean an undertaking typically requiring concerted effort that is focused on developing or maintaining a specific product or products. Typically, a project has its own funding, accounting, and delivery schedule. In a product line context, a project might be responsible for developing specific core assets or for developing a specific product from the core assets. A companion practice area is "Organizational Planning," which focuses on the strategic planning that transcends projects.

It is useful to distinguish between the process by which plans are created (the planning process) and the product of that process (the plans). Most planning processes are very similar regardless of the organizational level at which the plan is applied. They usually differ in the personnel involved and the scope of the planned effort. Generally, all planning processes should include

The planning process needs to be iterative and ongoing–after all, plans change. Plans should be updated and revised as needed during their lifespan.

Different types of plans address different purposes. Examples of project-oriented technical management plans include project plans, software development plans, quality assurance plans, configuration management plans, test plans, and technical risk management plans.

Although the contents of each plan should be tailored to fit its particular use, plans typically contain the following:

Other potential plan contents include responsibilities and commitments, work breakdown structures, resource and schedule estimates, risks, progress measures, relationships, and traceability to other plans.

The most usable plans have a particular focus. Planning a complex task often requires a set of interrelated plans that might have these relationships:

Aspects Peculiar to Product Lines

There is nothing fundamentally different about a planning process for a product line. However, certain types of technical plans are unique to product lines:

Project plans for product lines have a richer set of dependencies than those for single systems. They also have external dependencies among different groups and other plans, possibly at the organizational level, with relation to the core assets. Examples of project plans that may have dependencies include configuration management plans, funding plans, software integration plans, testing plans, and risk management plans.

Application to Core Asset Development

A product line effort requires work plans for core asset development and maintenance. These plans correspond to standard project plans, except that the "projects" in this case cover the development and maintenance of core assets (or subsets of the core assets). In addition to the generic plan contents identified earlier, these plans should also answer the following questions:

Whether you opt for a separate plan for each core asset or an overall "master" plan for the entire core asset effort depends on your context and culture. Don't overlook the fact that the plans themselves (or parts of the plans) make reusable core assets. Ideally, reusable plans should be tailorable in the same fashion as other core assets–that is, they have defined points of commonality and variability. Cost, effort, and schedule estimates may be particularly useful candidates for reuse, as are work breakdown structures, goals, strategies, and objectives.

In addition to the work plans for core assets, there is the production plan, which is, itself, a primary core asset. To develop a production plan, you need to understand who will be building the products–that is, the plan's audience. Production planning involves a combination of process definition and technical planning activities. The objective is to formulate a production strategy, production method, production process, and production project details that satisfy the organization's goals for the software product line.

Production plans can range from a detailed process model to a much more informal guidebook. The degree of specificity required in the production plan depends on the background of the intended product builders, the structure of the organization, the culture of the organization, and the concept of operations (CONOPS) for the product line. It helps to have at least a preliminary definition of the product line organization before developing the production plan.

The production plan should describe how specific tools are to be applied in order to use, tailor, and evolve the core assets. The production plan should also incorporate any metrics defined to measure organizational improvement as a result of the product line (or other process improvement) practices and the plan for collecting the data to feed those metrics. The production plan, like other core assets, should have variation points that permit tailoring to accommodate the needs of each product.

Application to Product Development

Each product development effort needs a plan to describe how the specific product will be produced using the core assets. That plan–the product production plan–is an instantiation of the production plan for the product line based on its variation points. The product production plan spells out the production process by including the attached processes for each core asset in that product. It helps the product developers use the core assets effectively to develop products.

In practice, a product production plan might only be derived conceptually–that is, the production process might be so easy or general that you don't have to literally make a concrete instance of it for each product. You can "mentally" derive it. Or it might be implicit due to automated derivation. That said, there are some things specific to each product that will be derived from the project details part of the production plan, such as the bill of materials, schedule, and so forth.

Example Practices

Production Planning Workshop: Chastek and McGregor developed a workshop for developing a product line production plan. It includes a guided session to determine the production goals, breakout discussions to define key development scenarios, a group work session to formulate the production strategy and prioritize the development scenarios, breakout groups to test the formulated strategy, development of a production method, and a discussion of the implications of that method for core asset design. For more information on production plans, see the work of these authors [Chastek 2004a, Chastek 2002b, Chastek 2002c].

Practice Risks

Poor-quality technical plans can fail to plot the needed tasks and fail to provide adequate resources for product line efforts. The result is a lack of confidence in the planners, missed deadlines, and poor quality due to desperate shortcuts. In particular, plans can suffer from the following:

Further Reading

[Chastek 2002b] & [Chastek 2002c] & [Chastek 2004a]
The works of Chastek, Donohoe, and McGregor provide a comprehensive guide and examples for developing a production plan.

[Diaz 2005a]
Diaz, Trujillo, and Anfurrutia describe how the production strategy accounts for variations at both the product and process level, thus impacting the production plan.

Next Section Table of Contents Previous Section