A Framework for Software Product Line Practice, Version 5.0

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

SEI Capability Maturity Model Integration models (CMMI), which contain essential elements of processes for software development in the categories of project management, engineering, support, and process management [SEI 2007h]
the International Standards Organization (ISO) 9000 series of quality standards. This set of general standards is applicable to the production of nearly any commodity, with the ISO 9001 standard being particularly pertinent to software development and maintenance [ISO 2007a].
software development methods that identify which processes to enact, such as agile methods or the Rational Unified Process (RUP). Some agile adherents may prefer to refer to these methods as "shared understandings" or "tacit knowledge" [Boehm 2004b].

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:

Facilitate human understanding and communication.
- Enable communication about and agreement on the software process.
- Provide sufficient information to allow an individual or team to perform the intended process.
- Form a basis for training individuals to follow the intended process.
Support management.
- Adapt a general software process to accommodate the attributes of a particular project, such as its product or organizational environment.
- Support the development of project plans.
- Monitor, manage, and coordinate the process.
- Provide a basis for process measurement, such as the definition of measurement points within the context of a specific process.
Support process improvement.
- Reuse well-defined and effective software processes on future projects.
- Estimate the impacts of potential changes in a software process before putting them into actual practice.
- Assist in the selection of models and tools and their incorporation into a process.

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

the operational concept for the product line, such as the one embodied in a product line concept of operations (CONOPS) (see the "Operations" practice area). The CONOPS is essentially the expression of an organization's product line enterprise process. Process definition skills must be brought to bear to build an operational definition that can be followed and improved and that will serve the goals of the product line. Process discipline is required to ensure that the operational concept is followed.
the attached processes that tell product builders how to instantiate core assets for specific products. The attached processes together form the production process, which in turn provides the content for the production plan. The production process must account for a wide variety of core assets and variations and accommodate the different role players who are going to carry out the process.
the production method that sets the implementation approach for the production plan by specifying the overall set of technologies, tools, and models to be used to produce products. The method provides the guidance core asset builders need to build core assets with appropriate variation mechanisms and their attached processes. The set of core assets and their attached processes must align with the product line's goals and be compatible with each other to form a cohesive, efficiently repeatable production process. The method can be an informally stated set of choices or more formally documented.

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:

What is the purpose of this activity?
Who participates in this activity?
What inputs are necessary to perform this activity?
What work products result from this activity?
How do you know when this activity should begin?
How do you know when this activity has been completed successfully?
What three-six subactivities do you perform to accomplish this activity (if the activity is decomposable)?
How do you determine or measure the performance of this activity?
What activities are performed before and after this 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:

process mismatch: There is a possibility of a process mismatch among a number of factors, such as the organizational structure, the organizational culture, the process that is employed, employees' experience and expertise, and the market to which the process is applicable. For example, the defined process may be too complex for the organization and therefore result in detailed practices that are not followed. On the other hand, the process may be too simplistic and thus too general and at too high a level to provide practical guidance.
process doesn't address the product line's needs: The process may not accommodate the connection between the processes for core asset and product development. This cross-flow is necessary for product line success.
inadequate process support: Processes must be supported within an organization, especially newly introduced ones. Lack of support (such as training, motivation, templates, and examples) will lead to failure of the process implementation.
uneven process quality: The divergent goals, skills, and backgrounds of development staff may lead to uneven quality in their process contributions. Those divergencies may also cause a lack of harmonization in the processes for the different development teams.
lack of buy-in: The organization may not buy into process discipline and therefore fail to adopt it.
dictatorial introduction: One organizational unit mandating the processes that another must follow is likely to result in resentment and the failure to adopt them.
processes not enforced: Even the best processes will fail to have their intended effect if they are not followed. Management needs to enforce the use of defined processes.
stagnant processes: Processes will need to be changed as the organization proceeds along its product line journey. Continuous process improvement is part of process discipline.