Achievement of process improvement within an individual process area. (See also “generic goal,” “specific goal,” “maturity level,” and “process area.”)
A capability level is defined by appropriate specific and generic goals for a process area.
A list of process areas and their corresponding capability levels. (See also “achievement profile,” “target profile,” and “target staging.”)
A capability level profile can be an “achievement profile” when it represents the organization’s progress for each process area while advancing through the capability levels. Or, it can be a “target profile” when it represents an objective for process
improvement.
A model that contains the essential elements of effective processes for one or more areas of interest and describes an evolutionary improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness.
A process that can satisfy its specified product quality, service quality, and process performance objectives. (See also “stable process” and “standard process.”)
The analysis of outcomes to determine their causes.
configuration control board
Judicious use of means to effect a change, or a proposed change, to a product or service. (See also “configuration management.”)
Capability Maturity Model
Capability Maturity Model Integration
The basic structure that organizes CMMI components, including elements of current CMMI models as well as rules and methods for generating models, appraisal methods (including associated artifacts), and training materials. (See also “CMMI model” and “CMMI
Product Suite.”)
The framework enables new areas of interest to be added to CMMI so that they will integrate with the existing ones.
A model generated from the CMMI Framework. (See also “CMMI Framework” and “CMMI Product Suite.”)
Any of the main architectural elements that compose a CMMI model.
Some of the main elements of a CMMI model include specific practices, generic practices, specific goals, generic goals, process areas, capability levels, and maturity levels.
The complete set of products developed around the CMMI concept. (See also “CMMI Framework” and “CMMI model.”)
These products include the framework itself, models, appraisal methods, appraisal materials, and training materials.
Carnegie Mellon University
Control Objectives for Information and related Technology
Items that can be purchased from a commercial supplier.
The variation of a process that exists because of normal and expected interactions among components of a process. (See also “special cause of variation.”)
An audit conducted to verify that a configuration item or a collection of configuration items that make up a baseline conforms to a specified standard or requirement. (See also “audit” and “configuration item.”)
The configuration information formally designated at a specific time during a product’s or product component’s life. (See also “product lifecycle.”)
Configuration baselines plus approved changes from those baselines constitute the current configuration information.
An element of configuration management consisting of the evaluation, coordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification. (See also “configuration
identification,” “configuration item,” and “configuration management.”)
A group of people responsible for evaluating and approving or disapproving proposed changes to configuration items and for ensuring implementation of approved changes. (See also “configuration item.”)
Configuration control boards are also known as “change control boards.”
An element of configuration management consisting of selecting the configuration items for a product, assigning unique identifiers to them, and recording their functional and physical characteristics in technical documentation. (See also “configuration
item,” “configuration management,” and “product.”)
An aggregation of work products that is designated for configuration management and treated as a single entity in the configuration management process. (See also “configuration management.”)
A discipline applying technical and administrative direction and surveillance to (1) identify and document the functional and physical characteristics of a configuration item, (2) control changes to those characteristics, (3) record and report change
processing and implementation status, and (4) verify compliance with specified requirements. (See also “configuration audit,” “configuration control,” “configuration identification,” and “configuration status accounting.”)
An element of configuration management consisting of the recording and reporting of information needed to manage a configuration effectively. (See also “configuration identification” and “configuration management.”)
This information includes a list of the approved configuration, the status of proposed changes to the configuration, and the implementation status of approved changes.
A collection of CMMI components that are used to construct models, training materials, and appraisal related documents for an area of interest (e.g., acquisition, development, services).
A capability maturity model structure wherein capability levels provide a recommended order for approaching process improvement within each specified process area. (See also “capability level,” “process area,” and “staged representation.”)
The result of the analysis and refinement of customer requirements into a set of requirements suitable to be included in one or more solicitation packages, or supplier agreements. (See also “acquirer,” “customer requirement,” “supplier agreement,” and
“solicitation package.”)
Contractual requirements include both technical and nontechnical requirements necessary for the acquisition of a product or service.
Acts or deeds used to remedy a situation or remove an error.
computer software configuration item

The party responsible for accepting the product or for authorizing payment.
The customer is external to the project or work group (except possibly in certain project structures in which the customer effectively is on the project team or in the work group) but not necessarily external to the organization. The customer can be a
higher level project or work group. Customers are a subset of stakeholders. (See also “stakeholder.”)
In most cases where this term is used, the preceding definition is intended; however, in some contexts, the term “customer” is intended to include other relevant stakeholders. (See also “customer requirement.”)
End users can be distinguished from customers if the parties that directly receive the value of products and services are not the same as the parties that arrange for, pay for, or negotiate agreements. In contexts where customers and end users are
essentially the same parties, the term “customer” can encompass both types. (See also “end user.”)

The result of eliciting, consolidating, and resolving conflicts among the needs, expectations, constraints, and interfaces of the product’s relevant stakeholders in a way that is acceptable to the customer. (See also “customer.”)