Process Area Capability Maturity Model Integration (CMMI)

The Capability Maturity Model Integration (CMMI) defines a Process Area as, “A cluster of related practices in an area that, when implemented collectively, satisfies a set of goals considered important for making improvement in that area.” Both CMMI for Development v1.3 and CMMI for Acquisition v1.3 identify 22 process areas, whereas CMMI for Services v1.3 identifies 24 process areas. Many of the process areas are the same in these three models.

In CMMI models, the process areas are organized in alphabetical order according to their acronym. However, process areas can be grouped according to maturity levels or process area categories.

There are Five maturity levels. However, maturity level ratings are awarded for levels 2 through 5. The process areas below and their maturity levels are listed for the CMMI for Development model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

The process areas below and their maturity levels are listed for the CMMI for Services model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined (this includes the process areas that make up the previous levels; Maturity Level 3 is made up of the process areas in Level 2 and Level 3)

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

The process areas below and their maturity levels are listed for the CMMI for Acquisition model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

There are two categories of goals and practices: generic and specific. Specific goals and practices are specific to a process area. Generic goals and practices are a part of every process area. A process area is satisfied when organizational processes cover all of the generic and specific goals and practices for that process area.

Generic goals and practices are a part of every process area.

Each process area is defined by a set of goals and practices. These goals and practices appear only in that process area.

CMMI for Development, Version 1.2 contains 22 process areas indicating the aspects of product and service development that are to be covered by organizational processes. For a summary of process areas for each model, see these quick reference documents available on the SEI website:

Purpose

The purpose of Agreement Management (AM) is to ensure that the supplier and the acquirer perform according to the terms of the supplier agreement.

Specific Practices by Goal

Purpose

The purpose of Capacity and Availability Management (CAM) is to ensure effective service system performance and
ensure that resources are provided and used effectively to support service requirements.

Specific Practices by Goal

Purpose

The purpose of Causal Analysis and Resolution (CAR) is to identify causes of selected outcomes and take action to improve process performance.

Specific Practices by Goal

Purpose

The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

Specific Practices by Goal

Purpose

The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.

Specific Practices by Goal

Purpose

The purpose of Integrated Project Management (IPM) is to establish and manage the project and the involvement of relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes.

Specific Practices by Goal

Purpose

The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability used to support management information needs.

Specific Practices by Goal

Purpose

The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets, work environment standards, and rules and guidelines for teams.

Specific Practices by Goal

Purpose

The purpose of Organizational Process Focus (OPF) is to plan, implement, and deploy organizational process improvements based on a thorough understanding of current strengths and weaknesses of the organization’s processes and process assets.

Specific Practices by Goal

Purpose

The purpose of Organizational Performance Management (OPM) is to proactively manage the organization’s performance to meet its business objectives.

Specific Practices by Goal

Purpose

The purpose of Organizational Process Performance (OPP) is to establish and maintain a quantitative understanding of the performance of selected processes in the organization’s set of standard processes in support of achieving quality and process performance objectives, and to provide process performance data, baselines, and models to quantitatively manage the organization’s projects.

Specific Practices by Goal

Purpose

The purpose of Organizational Training (OT) is to develop skills and knowledge of people so they can perform their roles effectively and efficiently.

Specific Practices by Goal

Purpose

The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, behaves properly (i.e., possesses the required functionality and quality attributes), and deliver the product.

Specific Practices by Goal

Purpose

The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.

Specific Practices by Goal

Purpose

The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.

Specific Practices by Goal

Purpose

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.

Specific Practices by Goal

Purpose

The purpose of the Quantitative Project Management (QPM) process area is to quantitatively manage the project to achieve the project’s established quality and process performance objectives.

Specific Practices by Goal

Purpose

The purpose of Requirements Development (RD) is to elicit, analyze, and establish customer, product, and product component requirements.

Specific Practices by Goal

Purpose

The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.

Specific Practices by Goal

Purpose

The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

Specific Practices by Goal

Purpose

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers.

Specific Practices by Goal

Purpose

The purpose of Technical Solution (TS) is to select design and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product related lifecycle processes either singly or in combination as appropriate.

Specific Practices by Goal

Purpose

The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.

Specific Practices by Goal

Purpose

The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.

Specific Practices by Goal

Only changes made to the set of Process Areas are considered here. For more information about the changes made to Version 1.2, see the Version 1.2 Release Notes or for the definitive list of changes, take the CMMI Version 1.2 Upgrade Training.

Some significant improvements in CMMI-DEV, V1.3 include the following:

For a more complete and detailed list of improvements, see http://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/comparison.cfm. An overview of the changes is described in http://www.benlinders.com/2011/cmmi-v1-3-summing-up/.

Table: Process Areas, Categories, and Maturity Levels

Get More PRINCE2 Information by Clicking HERE

Systems Design

Systems design is the process of defining the architecture, modules, interfaces, and data for a system to satisfy specified requirements. Systems design could be seen as the application of systems theory to product development. There is some overlap with the disciplines of systems analysis, systems architecture and systems engineering.

If the broader topic of product development “blends the perspective of marketing, design, and manufacturing into a single approach to product development,” then design is the act of taking the marketing information and creating the design of the product to be manufactured. Systems design is therefore the process of defining and developing systems to satisfy specified requirements of the user.

Until the 1990s, systems design had a crucial and respected role in the data processing industry. In the 1990s, standardization of hardware and software resulted in the ability to build modular systems. The increasing importance of software running on generic platforms has enhanced the discipline of software engineering.

The architectural design of a system emphasizes the design of the system architecture that describes the structure, behavior and more views of that system and analysis.

The logical design of a system pertains to an abstract representation of the data flows, inputs and outputs of the system. This is often conducted via modelling, using an over-abstract (and sometimes graphical) model of the actual system. In the context of systems, designs are included. Logical design includes entity-relationship diagrams (ER diagrams).

The physical design relates to the actual input and output processes of the system. This is explained in terms of how data is input into a system, how it is verified/authenticated, how it is processed, and how it is displayed.
In physical design, the following requirements about the system are decided.

Put another way, the physical portion of system design can generally be broken down into three sub-tasks:

User Interface Design is concerned with how users add information to the system and with how the system presents information back to them. Data Design is concerned with how the data is represented and stored within the system. Finally, Process Design is concerned with how data moves through the system, and with how and where it is validated, secured and/or transformed as it flows into, through and out of the system. At the end of the system design phase, documentation describing the three sub-tasks is produced and made available for use in the next phase.

Physical design, in this context, does not refer to the tangible physical design of an information system. To use an analogy, a personal computer’s physical design involves input via a keyboard, processing within the CPU, and output via a monitor, printer, etc. It would not concern the actual layout of the tangible hardware, which for a PC would be a monitor, CPU, motherboard, hard drive, modems, video/graphics cards, USB slots, etc.
It involves a detailed design of a user and a product database structure processor and a control processor. The H/S personal specification is developed for the proposed system.

Rapid application development (RAD) is a methodology in which a system designer produces prototypes for an end-user. The end-user reviews the prototype, and offers feedback on its suitability. This process is repeated until the end-user is satisfied with the final system.

Joint application design (JAD) is a methodology which evolved from RAD, in which a system designer consults with a group consisting of the following parties:

JAD involves a number of stages, in which the group collectively develops an agreed pattern for the design and implementation of the system.