A Framework for Software Product Line Practice, Version 5.0
Product Line Practice Areas
To achieve a software product line, you must carry out the three essential activities described in Product Line Essential Activities: core asset development, product development, and management. To be able to carry out the essential activities, you must master the practice areas relevant to each and apply them in a coordinated, focused fashion. By "mastering," we mean an ability to achieve repeatable, not just one-time, success.
A practice area is a body of work or a collection of activities that an organization must master to successfully carry out the essential work of a product line. Practice areas help to make the essential activities more achievable by defining activities that are smaller and more tractable than a broad imperative such as "develop core assets." Practice areas provide starting points from which organizations can make (and measure) progress in adopting a product line approach for software.
This framework defines the practice areas for product line practice. They all describe activities that are essential for any successful software development effort, not just software product lines. However, they all either take on particular significance or must be carried out in a unique way in a product line context. Those aspects that are specifically relevant to software product lines, as opposed to single-system development, are emphasized.
Describing the Practice Areas
For each practice area, we present the following information:
-
an introductory overview of the practice area that summarizes what it's about. You will not find a definitive discourse on the practice area here, since, in most cases, there is overlap with what can be found in traditional software engineering and management reference books. We provide a few basic references if you need a refresher.
-
those aspects of the practice area that apply especially to a product line, as opposed to a single system. Here, you will learn in what ways traditional software and management practice areas need to be refocused or tailored to support a product line approach.
-
how the practice area is applied to core asset development and product development, respectively. We separate these two essential activities in the framework. Although a given practice area typically applies to both of these broad areas, the focus will differ depending on whether you're building products or developing core assets.
-
a description of any example practices that are known to apply to the practice area. An example practice describes a particular way of accomplishing the work associated with a practice area. Example practices are not meant to be end-to-end methodological solutions to carrying out a practice area but rather approaches to the problem that have been used in practice to build product lines. Whether a given example practice will work for your organization depends on the particular context of your situation.
-
known risks associated with the practice area. These are ways in which a practice area can go wrong, to the detriment of the overall product line effort. Our understanding of these risks is borne out of the pitfalls of others in their product line efforts.
-
where possible, a list of references for further reading, to support your investigation in areas where you desire more depth
Organizing the Practice Areas
Since there are so many practice areas, we need a way of organizing them for easier access and reference. For this reason, we divide them loosely into three categories:
- Software engineering practice areas are those necessary for applying the appropriate technology to create and evolve both core assets and products.
- Technical management practice areas are those necessary for managing the creation and evolution of the core assets and the products.
- Organizational management practice areas are those necessary for orchestrating the entire software product line effort.
Each of these categories appeals to a different body of knowledge and requires a different skill set for the people who must carry them out. The categories represent disciplines rather than job titles.
The following figure shows how the three categories are related.
Relationships Among Categories of Practice Areas
There is no way to divide cleanly into practice areas the knowledge necessary to achieve a software product line. Some overlap is inevitable. We chose what we hope is a reasonable scheme and identified practice area overlap where possible.
The description of practice areas that follows is an encyclopedia; neither the ordering nor the categorization constitutes a method or an order for application. In other work, we provide product line practice patterns that show how to put the practice areas into play for a particular organization's context and goals [Clements 2002c, Northrop 2004a].
