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

Process Discipline

The "Process Discipline" practice area is about an organization's capability to define, follow, and improve processes. An essential aspect of software engineering is the discipline required for a group of people to work together cooperatively to solve a common problem. Humphrey defines the term software process as "a sequence of steps required to develop or maintain software" [Humphrey 1995a]. Defined processes set the bounds for each person's roles and responsibilities so that the collaboration is successful and efficient. This practice area is about the skills required to plan, define, and execute those various processes successfully.

A first step on the road to process discipline is to determine which processes need to be defined and plan how to do it. Advice on which software processes to enact is provided in various process models. Sheard shows the lineage of several such models [Sheard 1997a]. Widely used examples include

Once a particular process model is selected, there are methods for defining it. If an informal (albeit perhaps inconsistent) process exists already, it is useful to document it as a starting point. The SEI Process Change Methodology [Fowler 1999a] and the SEI Personal Software Process [Humphrey 1995a] take this tack. Interviews and stakeholder working sessions are useful in resolving differences about how the process is (or should be) defined. Once the current process is defined, you have a basis for following and improving it. (See the Example Practices in this section.)

An effective process definition is complete enough to get the job done but not so overspecified as to bog things down. At one end of the scale, some agile methods' tacit understandings of process may be adequate for small teams working on relatively simple tasks. For a somewhat more complex task involving more people, an effective process definition might be a simple checklist. For a much more complex task involving many people and specialized knowledge, a much more elaborate process definition may be necessary. While details vary, most process representation schemes require that you identify at least the activities that are performed, the agents that perform them, and the work products that result. The Object Management Group's Software Process Engineering Metamodel (SPEM) provides a more elaborate object-oriented scheme for representing software processes [OMG 2005a].

Ultimately, the process definition should be clear and complete enough to satisfy the following goals:

It is management's responsibility to provide support for defining and institutionalizing processes and ensuring that they are followed, coordinated, and improved. Often, management establishes a software engineering process group to carry out the details, while a management steering group provides overall planning and direction. A wealth of information is available on software process management. Zahran provides an introduction to the subject [Zahran 1998a]. Kasse describes process management and improvement that is centered on both the assessment of the current state and on follow-up actions to achieve the desired state [Kasse 2002a]. There are also international conferences and local Software Process Improvement Network (SPIN) chapters throughout the world [SEI 2006c].

Aspects Peculiar to Product Lines

If software engineering is about a group of people working together to solve a problem cooperatively, product line software engineering requires cooperation in spades. Because of the plurality of products and groups cooperating to develop those products, the entire apparatus will work to its potential only if everyone does his or her job within agreed-upon parameters. For example, no one is allowed to change core assets unilaterally. Core asset developers are not allowed to change them before understanding how the changes will affect the products in (or already out of) the production pipeline. Product developers are certainly not allowed to change them because "clone and own" is a poor form of reuse that is the antithesis of the product line approach. Core assets do indeed change but only as the result of all parties adhering to an agreed-upon process for making any changes.

Besides change control and configuration management other prime examples of product line processes are

Other product line activities also rely on process discipline to achieve their required fidelity. Launching a product line, carrying out technical and organizational planning and risk management activities, collecting and analyzing measures, performing make/buy/mine/commission analysis, and maintaining the correct customer interface all rely on adherence to processes that must be defined and followed. However, not all practice areas require processes of the same rigor. Whereas configuration management (CM) needs an industrial-strength, no-nonsense process that everyone must follow, an exploratory activity such as market analysis might not.

The expertise required to define the above processes varies depending on the type of process being created. The production method requires individuals with considerable technical currency and software design experience. For example, the core asset developers should be involved, since they understand the tools and models currently being used: both are important input to the production method. Those defining a measurement process would instead need to be skilled in defining measures and appropriate data collection and analysis activities.

Because product lines call for the repeated, ongoing, disciplined interaction of separate organizational entities, they rely heavily on the adherence to a process. Process discipline represents an area of expertise that enables many other practice areas to be executed successfully. For this reason, organizations that lack a strong process culture will find deploying a successful product line a perilous proposition [Clements 2002c, Jones 2002a].

Application to Core Asset Development

Each core asset has an attached process associated with it that explains how the asset is used to build products in the product line. Together, these attached processes form the product line's production process, which in turn is embodied in the production plan that shows how core assets are turned into products. The attached processes differ across core assets. For example, the way in which the product line requirements are used to express those for a specific product differs from the way in which the product line architecture is instantiated to architect the specific product. Since the people who create a core asset are usually not the people who use it, the attached process communicates the asset's intended use. The attached processes all follow the guidance of the production method. Process discipline is the vehicle by which the attached processes and the production method are specified and enforced.

In addition, there are processes that explain how core assets are created, evaluated, maintained, and evolved over the lifetime of the product line. Once again, process discipline is the mechanism by which these processes are defined, followed, and improved.

Application to Product Development

As part of the production plan, a core asset's attached process is the bridge between the core asset developers and the product developers; it is a way for the core asset builders to speak across any gulf to the product builders and tell them how the core assets should be used to create systems. Therefore, the attached processes have implications for product development as well as for core asset development. Good process definition skills provide easy-to-use, effective, and efficient attached processes; processes that are cumbersome or unwieldy will probably be discarded by product builders in favor of ad hoc, non-repeatable approaches.

Products, like core assets, also have rules for evolution and maintenance that must be captured in a process and then followed.

Example Practices

Example practices for process discipline include the following.

Creation and use of electronic process documents: These documents–which include Web-based process handbooks and electronic process guides–allow process definitions to be focused or presented in different ways to shield the process user from scores of unnecessary details. Instead, the electronic documentation displays a narrowed view that describes at any specific time the process steps that should be performed. Additionally, this approach makes it possible for automatic enforcement and tracking of process execution. In general, role-specific views of a process decrease the complexity of process definition and allow you to focus on those aspects of the process that are relevant to a specific user. Finkelstein, Kramer, and Nuseibeh give a fairly comprehensive overview of various modeling and documentation techniques [Finkelstein 1994a].

Integrated process support environments: These environments use computer systems to automate some of the required process steps, such as informing a quality assurance organization that a document is ready for review or sending a change request to core asset developers [Finkelstein 1994a].

A risk-based approach to choose between adaptive (i.e., agile) and predictive (i.e., plan-driven) process methods: Boehm and Turner recommend risk analysis that is based on how well a project aligns with a method's "home ground" [Boehm 2004b]. For example, the agile methods' home ground includes the characteristics of a small group of senior developers in an environment of frequent requirements change working on a system of low criticality, whereas the plan-driven methods' home ground includes the characteristics of a large number of junior developers in an environment of infrequent requirements change working on a system of high criticality.

Conducting a stakeholder workshop to capture the "as-is" process: Most of the time, there is already an informal process in place; it just may not be consistently understood and applied. Getting the process stakeholders together is an excellent way to clarify their understanding of the process, further crystallize its definition, and provide a basis for its execution and improvement. The Process Change Methodology suggests getting stakeholders to identify a list of the key activities that make up the process (including any conditional or iterative sequencing) and then answering the following questions for each activity:

Building on an existing software process improvement effort: Jones, Northrop, and Soule compared the CMMI models to determine the differences between CMMI process areas and to figure out what is needed to add product-line-specific aspects to those areas [Jones 2002a, Jones 2005a]. Jones further describes how to use an existing software process improvement infrastructure to support product line practice [Jones 2004a].

Use of Six Sigma techniques to select process improvements: Continuous process improvement is at the heart of the Six Sigma approach. It provides a philosophy, metrics, an improvement framework, and a toolkit of analytic methods aimed at improving customer satisfaction by eliminating defects. The approach has been used successfully either as the driving framework or a useful adjunct for other process improvement methodologies [Six Sigma 2007a].

Use of the Process pattern: This pattern specifies the practice areas that require processes and their relationships to the "Process Discipline" practice area. [Clements 2002c, Ch. 7].

Use of method engineering: Method engineering involves developing methods and has emerged in response to an increasing feeling that methods are not well suited to the needs of their users, the product developers [Rolland 1997a]. Method engineering practices, which involve integrating theory, guidelines, and tool support, can be used to produce the production method. Method engineering is similar to process engineering, which is why this practice is situated in the "Process Discipline" practice area [Marttiin 1998a].

Practice Risks

Poor process discipline will result in processes that are inappropriate, vague, unclear, overconstraining, or ineffective. As a result, employees will either choose not to follow them and carry out their work in an ad hoc manner or follow them but fail to achieve the desired results. In either case, the result will be resentment and mistrust of the processes and a poor-quality product line. Potential causes of process difficulties are as follows:

Further Reading

[Boehm 2004b]
Boehm and Turner compare various software development methodologies and provide a risk-driven approach for choosing the appropriate balance between agile and plan-driven processes.

[Curtis 1992a]
This paper written by Curtis, Kellner, and Over is probably the most referenced one in the software process modeling community. It is a must for anyone who wants to understand software development processes and process modeling.

[Humphrey 1992a]
Humphrey and Feiler provide an excellent source of definitions in process terminology that helped to create the basis for the process community.

[Finkelstein 1994a]
Finkelstein, Kramer, and Nuseibeh provide a fairly comprehensive overview of process-centered environments. Their work shows the different approaches and techniques and suggests tools for enacting defined processes.

[Jones 2002a]
Jones and Soule provide a comparison of CMMI and this framework.

[Jones 2005a]
Jones and Northrop provide a description of product line adoption that builds on an existing CMMI approach.

Next Section Table of Contents Previous Section