Chapter 2. Process Area Components

This chapter describes the components found in each process area, as well as in the generic goals and generic practices. Understanding the meaning of these components is critical to effectively using the information in Part Two of this book. If you are unfamiliar with the contents of Part Two, you may want to skim the Generic Goals and Generic Practices section of Part Two, along with a couple of process area sections, to get a general feel for the content and layout before reading this chapter.

Required, Expected, and Informative Components

Model components are grouped into three categories—required, expected, and informative—which reflect how to interpret them.

Required Components

Required components describe what an organization must achieve to satisfy a process area. This achievement must be visibly implemented in an organization’s processes. The required components in CMMI are the specific and generic goals. Goal satisfaction is used in appraisals as the basis for deciding whether a process area has been satisfied.

Expected Components

Expected components describe what an organization may implement to achieve a required component. Expected components guide those who implement improvements or perform appraisals. The expected components in CMMI are the specific and generic practices.

Before goals can be considered satisfied, either the practices as described, or acceptable alternatives to them, must be present in the planned and implemented processes of the organization.

Authors’ Note

The required and expected components are also referred to as the normative material (versus the informative material).

Informative Components

Informative components provide details that help organizations understand the required and expected components. Subpractices, typical work products, goal and practice titles, goal and practice notes, examples, and references are examples of informative model components.

For CMMI for Acquisition (CMMI-ACQ), typical supplier deliverables are added informative components due to the interaction between supplier and acquirer processes.

The CMMI glossary of terms in Part Three of this book is not a required, expected, or informative component of CMMI models. You should interpret the terms in the glossary in the context of the model component in which they appear.

Components Associated with Part Two

The model components associated with Part Two can be summarized to illustrate their relationships, as shown in Figure 2.1.

Figure 2.1. CMMI Model Components

image

Authors’ Note

All model components are important because the informative material helps you to understand the expected and required material. It is best to take these model components as a whole. If you understand all three types of material, you can then understand all the pieces and how they fit together to form a framework that can benefit your organization.

The following sections provide detailed descriptions of CMMI model components.

Process Areas

A process area is a cluster of related practices in an area that, when implemented collectively, satisfy a set of goals considered important for making improvement in that area.

There are 22 process areas, presented here in alphabetical order by acronym:

• Agreement Management (AM)

• Acquisition Requirements Development (ARD)

• Acquisition Technical Management (ATM)

• Acquisition Validation (AVAL)

• Acquisition Verification (AVER)

• Causal Analysis and Resolution (CAR)

• Configuration Management (CM)

• Decision Analysis and Resolution (DAR)

• Integrated Project Management (IPM)

• Measurement and Analysis (MA)

• Organizational Innovation and Deployment (OID)

• Organizational Process Definition (OPD)

• Organizational Process Focus (OPF)

Organizational Process Performance (OPP)

• Organizational Training (OT)

• Project Monitoring and Control (PMC)

• Project Planning (PP)

• Process and Product Quality Assurance (PPQA)

• Quantitative Project Management (QPM)

• Requirements Management (REQM)

• Risk Management (RSKM)

• Solicitation and Supplier Agreement Development (SSAD)

Authors’ Note

Every time we release a model someone tells us that the process areas are not in alphabetical order. Since most users after a short time refer to the process areas by their acronym, it made sense to list them alphabetically by acronym instead of by full name.

Purpose Statements

A purpose statement describes the purpose of the process area and is an informative component.

For example, the purpose statement of the Organizational Process Definition process area is “The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets and work environment standards.”

Authors’ Note

All purpose statements follow the same sentence structure and always contain the process area acronym. An easy way to find a process area in an electronic file is to search for part or all of the purpose statement.

Introductory Notes

The introductory notes section of the process area describes the major concepts covered in the process area and is an informative component.

An example from the introductory notes of the Project Planning process area is “Planning begins with requirements that define the product and project.”

Related Process Areas

The related process areas section lists references to related process areas and reflects the high-level relationships among the process areas. The related process areas section is an informative component.

An example of a reference found in the related process areas section of the Project Planning process area is “Refer to the Risk Management process area for more information about identifying and managing risks.”

Specific Goals

A specific goal describes the unique characteristics that must be present to satisfy the process area. A specific goal is a required model component and is used in appraisals to help determine whether a process area is satisfied.

For example, a specific goal from the Configuration Management process area is “Integrity of baselines is established and maintained.”

Only the statement of the specific goal is a required model component. The title of a specific goal (preceded by the goal number) and notes associated with the goal are considered informative model components.

Generic Goals

Generic goals are called generic because the same goal statement applies to multiple process areas. A generic goal describes the characteristics that must be present to institutionalize the processes that implement a process area. A generic goal is a required model component and is used in appraisals to determine whether a process area is satisfied. (See the Generic Goals and Generic Practices section in Part Two for a more detailed description of generic goals.)

An example of a generic goal is “The process is institutionalized as a defined process.”

Only the statement of the generic goal is a required model component. The title of a generic goal (preceded by the goal number) and notes associated with the goal are considered informative model components.

Specific Goal and Practice Summaries

The specific goal and practice summary provides a high-level summary of the specific goals, which are required components, and the specific practices, which are expected components. The specific goal and practice summary is an informative component.

Authors’ Note

The specific goal and practice summary shows you at a glance a high-level summary of what is contained in a process area.

Specific Practices

A specific practice is the description of an activity that is considered important in achieving the associated specific goal. The specific practices describe the activities that are expected to result in achievement of the specific goals of a process area. A specific practice is an expected model component.

For example, a specific practice from the Project Monitoring and Control process area is “Monitor commitments against those identified in the project plan.”

Only the statement of the specific practice is an expected model component. The title of a specific practice (preceded by the practice number) and notes associated with the specific practice are considered informative model components.

Typical Work Products

The typical work products section lists sample output from a specific practice. These examples are called typical work products because there are often other work products that are just as effective but are not listed. A typical work product is an informative model component.

For example, a typical work product for the specific practice “Monitor actual values of project planning parameters against the project plan” in the Project Monitoring and Control process area is “Records of significant deviations.”

Typical Supplier Deliverables

To aid the acquirer, typical supplier deliverables are also provided. A typical supplier deliverable represents an artifact that is input into or supports the acquirer’s implementation of the practice.

Authors’ Note

CMMI-ACQ includes a process area component called “typical supplier deliverables.” After extended discussion, this new component was included because it presents lists of often very valuable inputs to the acquirers’ processes that yield, in turn, the typical work products of the acquirers’ activities. These were included to enable synergy across the acquirer–supplier team, particularly when both organizations are using the same book of CMMI best practices. Supplier deliverables do not become evidence for appraisals as typical work products often do, but providing these deliverables may aid projects during early planning and acquisition requirements development so that a more complete solicitation can be prepared.

For example, a typical supplier deliverable for the specific practice “Perform activities with the supplier as specified in the supplier agreement” in the Agreement Management process area is “Supplier project progress and performance reports.”

Subpractices

A subpractice is a detailed description that provides guidance for interpreting and implementing a specific or generic practice. Subpractices may be worded as though they are prescriptive, but they are actually an informative component meant only to provide ideas that may be useful for process improvement.

For example, a subpractice for the specific practice “Take corrective action on identified issues” in the Project Monitoring and Control process area is “Determine and document the appropriate actions needed to address identified issues.”

Generic Practices

Generic practices are called generic because the same practice applies to multiple process areas. A generic practice is the description of an activity that is considered important in achieving the associated generic goal. A generic practice is an expected model component.

For example, a generic practice for the generic goal “The process is institutionalized as a managed process” is “Provide adequate resources for performing the process, developing the work products, and providing the services of the process.”

Only the statement of the generic practice is an expected model component. The title of a generic practice (preceded by the practice number) and notes associated with the practice are considered informative model components.

Supporting Informative Components

There are many places in the model where further information is needed to describe a concept. This informative material is provided in the form of the following components:

Notes

A note is text that can accompany nearly any other model component. It may provide detail, background, or rationale. A note is an informative model component.

For example, a note that accompanies the specific practice “Implement selected action proposals developed in causal analysis” in the Causal Analysis and Resolution process area is “Only changes that prove to be of value should be considered for broad implementation.”

Examples

An example is a component comprising text and often a list of items, usually in a box, that can accompany nearly any other component and provides one or more examples to clarify a concept or described activity. An example is an informative model component.

The following is an example that accompanies the subpractice “Document noncompliance issues when they cannot be resolved in the project” under the specific practice “Communicate quality issues and ensure the resolution of noncompliance issues with the staff and managers” in the Process and Product Quality Assurance process area.

References

A reference is a pointer to additional or more detailed information in related process areas and can accompany nearly any other model component. A reference is an informative model component.

For example, a reference that accompanies the specific practice “Select subprocesses that compose the project’s defined process based on historical stability and capability data” in the Quantitative Project Management process area is “Refer to the Organizational Process Definition process area for more information about the organization’s process asset library, which might include a process element of known and needed capability.”

Authors’ Note

The difference between a reference that appears in the Related Process Areas section of a process area and one that appears elsewhere in the process area is that the references in the Related Process Area section represent more fundamental or important relationships and apply to the whole process area.

Numbering Scheme

Specific and generic goals are numbered sequentially. Each specific goal begins with the prefix SG (e.g., SG 1). Each generic goal begins with the prefix GG (e.g., GG 2).

Specific and generic practices also are numbered sequentially. Each specific practice begins with the prefix SP, followed by a number in the form x.y (e.g., SP 1.1). The x is the same number as the goal to which the specific practice maps. The y is the sequence number of the specific practice under the specific goal.

An example of specific practice numbering is in the Project Planning process area. The first specific practice is numbered SP 1.1 and the second is SP 1.2.

Each generic practice begins with the prefix GP, followed by a number in the form x.y (e.g., GP 1.1).

The x corresponds to the number of the generic goal. The y is the sequence number of the generic practice under the generic goal. For example, the first generic practice associated with GP 2 is numbered GP 2.1 and the second is GP 2.2.

Typographical Conventions

The typographical conventions used in this model were designed to enable you to select what you need and use it effectively. We present model components in formats that allow you to find them quickly on the page.

Figures 2.2 and 2.3 are sample pages from process areas in Part Two; they show the different process area components, labeled so that you can identify them. Notice that components differ typographically so that you can easily identify each one.

Figure 2.2. Sample Page from Decision Analysis and Resolution

image

Figure 2.3. Sample Page from Acquisition Technical Management

image
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.145.106.127