The criteria that a deliverable must satisfy to be accepted by a user, customer, or other authorized entity. (See also “deliverable.”)

Formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a deliverable. (See also “unit testing.”)

A list of process areas and their corresponding capability levels that represent the organization’s progress for each process area while advancing through the capability levels. (See also “capability level profile,” “target profile,” and “target staging.”)

The stakeholder that acquires or procures a product or service from a supplier. (See also “stakeholder.”)

The process of obtaining products or services through supplier agreements. (See also “supplier agreement.”)

The specific approach to acquiring products and services that is based on considerations of supply sources, acquisition methods, requirements specification types, agreement types, and related acquisition risks.

A clearly marked model component that contains information of interest to particular users.
In a CMMI model, all additions bearing the same name can be optionally selected as a group for use. In CMMI for Services, the Service System Development (SSD) process area is an addition.

Requirement that results from levying all or part of a higher level requirement on a lower level architectural element or design component.
More generally, requirements can be allocated to other logical or physical components including people, consumables, delivery increments, or the architecture as a whole, depending on what best enables the product or service to achieve the requirements.

American National Standards Institute

application program interface

An examination of one or more processes by a trained team of professionals using an appraisal reference model as the basis for determining, at a minimum, strengths and weaknesses.
This term has a special meaning in the CMMI Product Suite besides its common standard English meaning.

The results of an appraisal that identify the most important issues, problems, or opportunities for process improvement within the appraisal scope.
Appraisal findings are inferences drawn from corroborated objective evidence.

Members of the organizational unit who participate in providing information during an appraisal.

The value assigned by an appraisal team to (a) a CMMI goal or process area, (b) the capability level of a process area, or (c) the maturity level of an organizational unit.
This term is used in CMMI appraisal materials such as the SCAMPI MDD. A rating is determined by enacting the defined rating process for the appraisal method being employed.

The CMMI model to which an appraisal team correlates implemented process activities.
This term is used in CMMI appraisal materials such as the SCAMPI MDD.

The definition of the boundaries of an appraisal encompassing the organizational limits and CMMI model limits within which the processes to be investigated operate.
This term is used in CMMI appraisal materials such as the SCAMPI MDD.

Appraisal Requirements for CMMI

The set of structures needed to reason about a product. These structures are comprised of elements, relations among them, and properties of both.
In a service context, the architecture is often applied to the service system.
Note that functionality is only one aspect of the product. Quality attributes, such as responsiveness, reliability, and security, are also important to reason about. Structures provide the means for highlighting different portions of the architecture. (See also “functional architecture.”)

An objective examination of a work product or set of work products against specific criteria (e.g., requirements). (See also “objectively evaluate.”)
This is a term used in several ways in CMMI, including configuration audits and process compliance audits.

Measure defined in terms of an attribute and the method for quantifying it. (See also “derived measure.”)
A base measure is functionally independent of other measures.

A set of specifications or work products that has been formally reviewed and agreed on, which thereafter serves as the basis for further development, and which can be changed only through change control procedures. (See also “configuration baseline” and “product baseline.”)

An association among two or more logical entities that is discernable in either direction (i.e., to and from an entity). (See also “requirements traceability” and “traceability.”)

(See “organization’s business objectives.”)

computer-aided design

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.”)

Causal Analysis and Resolution (process area)

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 level

Configuration Management (process area)

CMMI Model Foundation

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.

CMMI for Acquisition

CMMI for Development

CMMI for Services

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.”)

(See “supplier.”)

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.

commercial off-the-shelf

cost performance index

critical path method

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.”)

Decision Analysis and Resolution (process area)

Recorded information.
Recorded information can include technical data, computer software documents, financial information, management information, representation of facts, numbers, or datum of any nature that can be communicated, stored, and processed.

The disciplined processes and systems that plan for, acquire, and provide stewardship for business and technical data, consistent with data requirements, throughout the data lifecycle.

Number of defects per unit of product size.
An example is the number of problem reports per thousand lines of code.

A managed process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines; has a maintained process description; and contributes process related experiences to the organizational process assets. (See also “managed process.”)

A characterization of required functionality and quality attributes obtained through “chunking,” organizing, annotating, structuring, or formalizing the requirements (functional and non-functional) to facilitate further refinement and reasoning about the requirements as well as (possibly, initial) solution exploration, definition, and evaluation. (See also “architecture,” “functional architecture,” and “quality attribute.”)
As technical solution processes progress, this characterization can be further evolved into a description of the architecture versus simply helping scope and guide its development, depending on the engineering processes used; requirements specification and architectural languages used; and the tools and the environment used for product or service system development.

An item to be provided to an acquirer or other designated recipient as specified in an agreement. (See also “acquirer.”)
This item can be a document, hardware item, software item, service, or any type of work product.

The complete set of circumstances and conditions under which services are delivered in accordance with service agreements. (See also “service” and “service agreement.”)
The delivery environment encompasses everything that has or can have a significant effect on service delivery, including but not limited to service system operation, natural phenomena, and the behavior of all parties, whether or not they intend to have such an effect. For example, consider the effect of weather or traffic patterns on a transportation service. (See also “service system.”)
The delivery environment is uniquely distinguished from other environments (e.g., simulation environments, testing environments). The delivery environment is the one in which services are actually delivered and count as satisfying a service agreement.

Measure that is defined as a function of two or more values of base measures. (See also “base measure.”)

Requirements that are not explicitly stated in customer requirements but are inferred (1) from contextual requirements (e.g., applicable standards, laws, policies, common practices, management decisions) or (2) from requirements needed to specify a product or service component.
Derived requirements can also arise during analysis and design of components of the product or service. (See also “product requirements.”)

A formal, documented, comprehensive, and systematic examination of a design to determine if the design meets the applicable requirements, to identify problems, and to propose solutions.

To create a product or service system by deliberate effort.
In some contexts, development can include the maintenance of the developed product.

Department of Homeland Security

A collection of data, regardless of the medium on which it is recorded, that generally has permanence and can be read by humans or machines.
Documents include both paper and electronic documents.

Department of Defense

Electronic Industries Alliance

Electronic Industries Alliance/Interim Standard

A party that ultimately uses a delivered product or that receives the benefit of a delivered service. (See also “customer.”)
End users may or may not also be customers (who can establish and accept agreements or authorize payments).
In contexts where a single service agreement covers multiple service deliveries, any party that initiates a service request can be considered an end user. (See also “service agreement” and “service request.”)

The full composition of a company. (See also “organization.”)
A company can consist of many organizations in many locations with different customers.

States of being that must be present before an effort can begin successfully.

A target staging, created using the continuous representation that is defined so that the results of using the target staging can be compared to maturity levels of the staged representation. (See also “capability level profile,” “maturity level,” “target profile,” and “target staging.”)
Such staging permits benchmarking of progress among organizations, enterprises, projects, and work groups, regardless of the CMMI representation used. The organization can implement components of CMMI models beyond the ones reported as part of equivalent staging. Equivalent staging relates how the organization compares to other organizations in terms of maturity levels.

Create, document, use, and revise work products as necessary to ensure they remain useful.
The phrase “establish and maintain” plays a special role in communicating a deeper principle in CMMI: work products that have a central or key role in work group, project, and organizational performance should be given attention to ensure they are used and useful in that role.
This phrase has particular significance in CMMI because it often appears in goal and practice statements (though in the former as "established and maintained") and should be taken as shorthand for applying the principle to whatever work product is the object of the phrase.

An informative model component that provides sample outputs from a specific practice.

(See “senior manager.”)

States of being that must be present before an effort can end successfully.

CMMI components that describe the activities that are important in achieving a required CMMI component.
Model users can implement the expected components explicitly or implement equivalent practices to these components. Specific and generic practices are expected model components.

functional configuration audit

(See “appraisal findings.”)

failure mode and effects analysis

A structured approach to evaluating alternative solutions against established criteria to determine a recommended solution to address an issue.

(See “CMMI Framework.”)

Examination of a defined function to identify all the subfunctions necessary to accomplish that function; identification of functional relationships and interfaces (internal and external) and capturing these relationships and interfaces in a functional architecture; and flow down of upper level requirements and assignment of these requirements to lower level subfunctions. (See also “functional architecture.”)

The hierarchical arrangement of functions, their internal and external (external to the aggregation itself) functional interfaces and external physical interfaces, their respective requirements, and their design constraints. (See also “architecture,” “functional analysis,” and “definition of required functionality and quality attributes.”)

A required model component that describes characteristics that must be present to institutionalize processes that implement a process area. (See also “institutionalization.”)

An expected model component that is considered important in achieving the associated generic goal.
The generic practices associated with a generic goal describe the activities that are expected to result in achievement of the generic goal and contribute to the institutionalization of the processes associated with a process area.

An informative model component that appears after a generic practice to provide guidance on how the generic practice could be applied uniquely to a process area. (This model component is not present in all CMMI models.)

generic goal

generic practice

The application of a systematic, disciplined, and quantifiable approach to transforming a set of requirements that represent the collection of stakeholder needs, expectations, and constraints, using documented techniques and technology to design, implement, and maintain a tangible product. (See also “software engineering” and “systems engineering.”)
In CMMI, hardware engineering represents all technical fields (e.g., electrical, mechanical) that transform requirements and ideas into tangible products.

The person or persons who provide the policy and overall guidance for the process but do not provide the direct day-to-day monitoring and controlling of the process. (See also “senior manager.”)
Such persons belong to a level of management in the organization above the immediate level responsible for the process and can be (but are not necessarily) senior managers.

International Business Machines

Initiating, Diagnosing, Establishing, Acting, Learning

Institute of Electrical and Electronics Engineers

A process that is not performed or is performed only partially; one or more of the specific goals of the process area are not satisfied.
An incomplete process is also known as capability level 0.

International Council on Systems Engineering

CMMI components that help model users understand the required and expected components of a model.
These components can be examples, detailed explanations, or other helpful information. Subpractices, notes, references, goal titles, practice titles, sources, example work products, and generic practice elaborations are informative model components.

The ingrained way of doing business that an organization follows routinely as part of its corporate culture.

In configuration management, the process of (1) identifying all functional and physical characteristics relevant to the interfacing of two or more configuration items provided by one or more organizations and (2) ensuring that proposed changes to these characteristics are evaluated and approved prior to implementation. (See also “configuration item” and “configuration management.”)

Integrated Product Development Capability Maturity Model

Integrated Project Management (process area)

International Organization for Standardization

International Organization for Standardization and International Electrotechnical Commission

Information Technology Infrastructure Library

A partitioning of the life of a product, service, project, work group, or set of work activities into phases.

Measurement and Analysis (process area)

A performed process that is planned and executed in accordance with policy; employs skilled people having adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description. (See also “performed process.”)

A person who provides technical and administrative direction and control to those who perform tasks or activities within the manager’s area of responsibility.
This term has a special meaning in the CMMI Product Suite besides its common standard English meaning. The traditional functions of a manager include planning, organizing, directing, and controlling work within an area of responsibility.

Degree of process improvement across a predefined set of process areas in which all goals in the set are attained. (See also “capability level” and “process area.”)

Method Definition Document

Variable to which a value is assigned as a result of measurement. (See also “base measure,” “derived measure,” and “measurement.”)
The definition of this term in CMMI is consistent with the definition of this term in ISO 15939.

A set of operations to determine the value of a measure. (See also “measure.”)
The definition of this term in CMMI is consistent with the definition of this term in ISO 15939.

A value determined by performing a measurement. (See also “measurement.”)

Binding document of understanding or agreement between two or more parties.
A memorandum of agreement is also known as a “memorandum of understanding.”

maturity level

The inherent range of variation in a process, as determined by process performance measures.
Natural bounds are sometimes referred to as “voice of the process.”
Techniques such as control charts, confidence intervals, and prediction intervals are used to determine whether the variation is due to common causes (i.e., the process is predictable or stable) or is due to some special cause that can and should be identified and removed. (See also “measure” and “process performance.”)

National Defense Industrial Association

An item that was developed prior to its current use in an acquisition or development process.
Such an item can require minor modifications to meet the requirements of its current intended use.

Requirements affecting product and service acquisition or development that are not properties of the product or service.
Examples include numbers of products or services to be delivered, data rights for delivered COTS and nondevelopmental items, delivery dates, and milestones with exit criteria. Other nontechnical requirements include work constraints associated with training, site provisions, and deployment schedules.

To review activities and work products against criteria that minimize subjectivity and bias by the reviewer. (See also “audit.”)
An example of an objective evaluation is an audit against requirements, standards, or procedures by an independent quality assurance function.

Organizational Innovation and Deployment (former process area)

Organizational Process Definition (process area)

A general description of the way in which an entity is used or operates.
An operational concept is also known as “concept of operations.”

A description of an imagined sequence of events that includes the interaction of the product or service with its environment and users, as well as interaction among its product or service components.
Operational scenarios are used to evaluate the requirements and design of the system and to verify and validate the system.

Organizational Process Focus (process area)

Organizational Performance Management (process area)

Organizational Process Performance (process area)

An administrative structure in which people collectively manage one or more projects or work groups as a whole, share a senior manager, and operate under the same policies.
However, the word “organization” as used throughout CMMI models can also apply to one person who performs a function in a small organization that might be performed by a group of people in a large organization. (See also “enterprise.”)

The extent to which an organization has explicitly and consistently deployed processes that are documented, managed, measured, controlled, and continually improved.
Organizational maturity can be measured via appraisals.

A guiding principle typically established by senior management that is adopted by an organization to influence and determine decisions.

Artifacts that relate to describing, implementing, and improving processes.
Examples of these artifacts include policies, measurement descriptions, process descriptions, process implementation support tools.
The term “process assets” is used to indicate that these artifacts are developed or acquired to meet the business objectives of the organization and that they represent investments by the organization that are expected to provide current and future business value. (See also “process asset library.”)

Senior-management-developed objectives designed to ensure an organization’s continued existence and enhance its profitability, market share, and other factors influencing the organization’s success. (See also “quality and process performance objectives” and “quantitative objective.”)

A repository used to collect and make measurement results available on processes and work products, particularly as they relate to the organization’s set of standard processes.
This repository contains or references actual measurement results and related information needed to understand and analyze measurement results.

A library of information used to store and make process assets available that are useful to those who are defining, implementing, and managing processes in the organization.
This library contains process assets that include process related documentation such as policies, defined processes, checklists, lessons learned documents, templates, standards, procedures, plans, and training materials.

A collection of definitions of the processes that guide activities in an organization.
These process descriptions cover the fundamental process elements (and their relationships to each other such as ordering and interfaces) that should be incorporated into the defined processes that are implemented in projects, work groups, and work across the organization. A standard process enables consistent development and maintenance activities across the organization and is essential for long-term stability and improvement. (See also “defined process” and “process element.”)

Organizational Training (process area)

(See “acquisition.”)

People Capability Maturity Model

physical configuration audit

The review of work products performed by peers during the development of work products to identify defects for removal. (See also “work product.”)
The term “peer review” is used in the CMMI Product Suite instead of the term “work product inspection.”

The measures of effectiveness and other key measures used to guide and control progressive development.

A process that accomplishes the needed work to produce work products; the specific goals of the process area are satisfied.

Program Evaluation and Review Technique

Product Integration (process area)

A process that is documented by both a description and a plan.
The description and plan should be coordinated and the plan should include standards, requirements, objectives, resources, and assignments.

Project Monitoring and Control (process area)

(See “organizational policy.”)

Project Planning (process area)

Process and Product Quality Assurance (process area)

A set of interrelated activities, which transform inputs into outputs, to achieve a given purpose. (See also “process area,” “subprocess,” and “process element.”)
There is a special use of the phrase “the process” in the statements and descriptions of the generic goals and generic practices. “The process,” as used in Part Two, is the process or processes that implement the process area.
The terms “process,” “subprocess” and “process element” form a hierarchy with “process” as the highest, most general term, “subprocesses” below it, and “process element” as the most specific. A particular process can be called a subprocess if it is part of another larger process. It can also be called a process element if it is not decomposed into subprocesses.
This definition of process is consistent with the definition of process in ISO 9000, ISO 12207, ISO 15504, and EIA 731.

A plan, usually resulting from appraisals, that documents how specific improvements targeting the weaknesses uncovered by an appraisal will be implemented.

A team that has the responsibility to develop and implement process improvement activities for an organization as documented in a process action plan.

Incremental and innovative improvements to processes and to process, product, or service technologies.

(1) The ordering, interfaces, interdependencies, and other relationships among the process elements in a standard process, or (2) the interfaces, interdependencies, and other relationships between process elements and external processes.

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.

Anything the organization considers useful in attaining the goals of a process area. (See also “organizational process assets.”)

A collection of process asset holdings that can be used by an organization, project, or work group. (See also “organization’s process asset library.”)

A measurable characteristic of process capability applicable to any process.

The range of expected results that can be achieved by following a process.

The act of defining and describing a process.

A documented expression of a set of activities performed to achieve a given purpose.
A process description provides an operational definition of the major components of a process. The description specifies, in a complete, precise, and verifiable manner, the requirements, design, behavior, or other characteristics of a process. It also can include procedures for determining whether these provisions have been satisfied. Process descriptions can be found at the activity, project, work group, or organizational level.

The fundamental unit of a process.
A process can be defined in terms of subprocesses or process elements. A subprocess is a process element when it is not further decomposed into subprocesses or process elements. (See also “process” and “subprocess.”)
Each process element covers a closely related set of activities (e.g., estimating element, peer review element). Process elements can be portrayed using templates to be completed, abstractions to be refined, or descriptions to be modified or used. A process element can be an activity or task.
The terms “process,” “subprocess,” and “process element” form a hierarchy with “process” as the highest, most general term, “subprocesses” below it, and “process element” as the most specific.

A collection of specialists who facilitate the definition, maintenance, and improvement of processes used by the organization.

A program of activities designed to improve the process performance and maturity of the organization’s processes, and the results of such a program.

A set of target characteristics established to guide the effort to improve an existing process in a specific, measurable way either in terms of resultant product or service characteristics (e.g., quality, product performance, conformance to standards) or in the way in which the process is executed (e.g., elimination of redundant process steps, combination of process steps, improvement of cycle time). (See also “organization’s business objectives” and “quantitative objective.”)

A plan for achieving organizational process improvement objectives based on a thorough understanding of current strengths and weaknesses of the organization’s processes and process assets.

A set of operations used to determine values of measures of a process and its resulting products or services for the purpose of characterizing and understanding the process. (See also “measurement.”)

The person (or team) responsible for defining and maintaining a process.
At the organizational level, the process owner is the person (or team) responsible for the description of a standard process; at the project or work group level, the process owner is the person (or team) responsible for the description of the defined process. A process can therefore have multiple owners at different levels of responsibility. (See also “defined process” and “standard process.”)

A measure of results achieved by following a process. (See also “measure.”)
Process performance is characterized by both process measures (e.g., effort, cycle time, defect removal efficiency) and product or service measures (e.g., reliability, defect density, response time).

A documented characterization of process performance, which can include central tendency and variation. (See also “process performance.”)
A process performance baseline can be used as a benchmark for comparing actual process performance against expected process performance.

A description of relationships among the measurable attributes of one or more processes or work products that is developed from historical process performance data and is used to predict future performance. (See also “measure.”)
One or more of the measureable attributes represent controllable inputs tied to a subprocess to enable performance of “what-if” analyses for planning, dynamic re-planning, and problem resolution. Process performance models include statistical, probabilistic and simulation based models that predict interim or final results by connecting past performance with future outcomes. They model the variation of the factors, and provide insight into the expected range and variation of predicted results. A process performance model can be a collection of models that (when combined) meet the criteria of a process performance model.

Making, altering, or adapting a process description for a particular end.
For example, a project or work group tailors its defined process from the organization’s set of standard processes to meet objectives, constraints, and the environment of the project or work group. (See also “defined process,” “organization’s set of standard processes,” and “process description.”)

A work product that is intended for delivery to a customer or end user.
This term has a special meaning in the CMMI Product Suite besides its common standard English meaning. The form of a product can vary in different contexts. (See also “customer,” “product component,” “service,” and “work product.”)

The initial approved technical data package defining a configuration item during the production, operation, maintenance, and logistic support of its lifecycle. (See also “configuration item,” “configuration management,” and “technical data package.”)
This term is related to configuration management.

A work product that is a lower level component of the product. (See also “product” and “work product.”)
Product components are integrated to produce the product. There can be multiple levels of product components.
Throughout the process areas, where the terms “product” and “product component” are used, their intended meanings also encompass services, service systems, and their components.
This term has a special meaning in the CMMI Product Suite besides its common standard English meaning.

A complete specification of a product or service component, including fit, form, function, performance, and any other requirement.
The period of time, consisting of phases, that begins when a product or service is conceived and ends when the product or service is no longer available for use.

The period of time, consisting of phases, that begins when a product or service is conceived and ends when the product or service is no longer available for use.
Since an organization can be producing multiple products or services for multiple customers, one description of a product lifecycle may not be adequate. Therefore, the organization can define a set of approved product lifecycle models. These models are typically found in published literature and are likely to be tailored for use in an organization.
A product lifecycle could consist of the following phases: (1) concept and vision, (2) feasibility, (3) design/development, (4) production, and (5) phase out.

A group of products sharing a common, managed set of features that satisfy specific needs of a selected market or mission and that are developed from a common set of core assets in a prescribed way. (See also “service line.”)
The development or acquisition of products for the product line is based on exploiting commonality and bounding variation (i.e., restricting unnecessary product variation) across the group of products. The managed set of core assets (e.g., requirements, architectures, components, tools, testing artifacts, operating procedures, software) includes prescriptive guidance for their use in product development. Product line operations involve interlocking execution of the broad activities of core asset development, product development, and management.
Many people use “product line” just to mean the set of products produced by a particular business unit, whether they are built with shared assets or not. We call that collection a "portfolio," and reserve "product line" to have the technical meaning given here.

Processes associated with a product or service throughout one or more phases of its life (e.g., from conception through disposal), such as manufacturing and support processes.

A refinement of customer requirements into the developers’ language, making implicit requirements into explicit derived requirements. (See also “derived requirements” and “product component requirements.”)
The developer uses product requirements to guide the design and building of the product or service.

(See “CMMI Product Suite.”)

A refinement of customer requirements into the developers’ language, making implicit requirements into explicit derived requirements. (See also “derived requirements” and “product component requirements.”)
The developer uses product requirements to guide the design and building of the product or service.
The developer uses product requirements to guide the design and building of the product or service.

A plan that provides the basis for performing and controlling the project’s activities, which addresses the commitments to the project’s customer.
Project planning includes estimating the attributes of work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analyzing project risks. Iterating through these activities may be necessary to establish the project plan.

What a project achieves with respect to implementing project plans, including effort, cost, schedule, and technical performance. (See also “technical performance.”)

When a set of interrelated resources for a project are directed to develop or deliver one or more products or services for a customer or end user. (See also “project.”)

A preliminary type, form, or instance of a product, service, product component, or service component that serves as a model for later stages or for the final, complete version of the product or service.
This model of the product or service (e.g., physical, electronic, digital, analytical) can be used for the following (and other) purposes:
• Assessing the feasibility of a new or unfamiliar technology
• Assessing or mitigating technical risk
• Validating requirements
• Demonstrating critical features
• Qualifying a product or service
• Qualifying a process
• Characterizing performance or features of the product or service
• Elucidating physical principles

Quality Function Deployment

Quantitative Project Management (process area)

Requirements Development (process area)

A stakeholder that is identified for involvement in specified activities and is included in a plan. (See also “stakeholder.”)

The organization, use, and presentation of a CMM’s components.
Overall, two types of approaches to presenting best practices are evident: the staged representation and the continuous representation.

Requirements Management (process area)

CMMI components that are essential to achieving process improvement in a given process area.
Specific goals and generic goals are required model components. Goal satisfaction is used in appraisals as the basis for deciding whether a process area has been satisfied.

(1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a product, service, product component, or service component to satisfy a supplier agreement, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2). (See also “supplier agreement.”)

The determination of product or service specific functional and quality attribute characteristics based on analyses of customer needs, expectations, and constraints; operational concept; projected utilization environments for people, products, services, and processes; and measures of effectiveness. (See also “operational concept.”)

Using systematic techniques such as prototypes and structured surveys to proactively identify and document customer and end-user needs.

The management of all requirements received by or generated by the project or work group, including both technical and nontechnical requirements as well as those requirements levied on the project or work group by the organization. (See also “nontechnical requirements.”)

A discernable association between requirements and related requirements, implementations, and verifications. (See also “bidirectional traceability” and “traceability.”)

The ratio of revenue from output (product or service) to production costs, which determines whether an organization benefits from performing an action to produce something.

The evaluation, classification, and prioritization of risks.

An organized, thorough approach used to seek out probable or realistic risks in achieving objectives.

An organized, analytic process used to identify what might cause harm or loss (identify risks); to assess and quantify the identified risks; and to develop and, if needed, implement an appropriate approach to prevent or handle causes of risk that could result in significant harm or loss.
Typically, risk management is performed for the activities of a project, a work group, an organization, or other organizational units that are developing or delivering products or services.

Risk Management (process area)

Software Acquisition Capability Maturity Model

Supplier Agreement Management (process area)

Standard CMMI Appraisal Method for Process Improvement

Systems Engineering Capability Assessment Model

Systems Engineering Capability Model

Software Engineering Institute

A management role at a high enough level in an organization that the primary focus of the person filling the role is the long-term vitality of the organization rather than short-term concerns and pressures. (See also “higher level management.”)
A senior manager has authority to direct the allocation or reallocation of resources in support of organizational process improvement effectiveness.
A senior manager can be any manager who satisfies this description, including the head of the organization. Synonyms for senior manager include “executive” and “top-level manager.” However, to ensure consistency and usability, these synonyms are not used in CMMI models.
This term has a special meaning in the CMMI Product Suite besides its common standard English meaning.

A product that is intangible and non-storable. (See also “product,” “customer,” and “work product.”)
Services are delivered through the use of service systems that have been designed to satisfy service requirements. (See also “service system.”)
Many service providers deliver combinations of services and goods. A single service system can deliver both types of products. For example, a training organization can deliver training materials along with its training services.
Services may be delivered through combinations of manual and automated processes.
This term has a special meaning in the CMMI Product Suite besides its common standard English meaning.

A binding, written record of a promised exchange of value between a service provider and a customer. (See also “customer.”)
Service agreements can be fully negotiable, partially negotiable, or non-negotiable, and they can be drafted either by the service provider, the customer, or both, depending on the situation.
A “promised exchange of value” means a joint recognition and acceptance of what each party will provide to the other to satisfy the agreement. Typically, the customer provides payment in return for delivered services, but other arrangements are possible.
A “written” record need not be contained in a single document or other artifact. Alternatively, it may be extremely brief for some types of services (e.g., a receipt that identifies a service, its price, its recipient).

A list or repository of standardized service definitions.
Service catalogs can include varying degrees of detail about available service levels, quality, prices, negotiable/tailorable items, and terms and conditions.
A service catalog need not be contained in a single document or other artifact, and can be a combination of items that provide equivalent information (such as web pages linked to a database.) Alternatively, for some services an effective catalog can be a simple printed menu of available services and their prices.
Service catalog information can be partitioned into distinct subsets to support different types of stakeholders (e.g., customers, end users, provider staff, suppliers).

An indication of an actual or potential interference with a service.
Service incidents can occur in any service domain because customer and end-user complaints are types of incidents and even the simplest of services can generate complaints.
The word “incident” can be used in place of “service incident” for brevity when the context makes the meaning clear.

A defined magnitude, degree, or quality of service delivery performance. (See also “service” and “service level measure.”)

A service agreement that specifies delivered services; service measures; levels of acceptable and unacceptable services; and expected responsibilities, liabilities, and actions of both the provider and customer in anticipated situations. (See also “measure,” service,” and “service agreement.”)
A service level agreement is a kind of service agreement that documents the details indicated in the definition.
The use of the term “service agreement” always includes “service level agreement” as a subcategory and the former may be used in place of the latter for brevity. However, “service level agreement” is the preferred term when it is desired to emphasize situations in which distinct levels of acceptable services exist, or other details of a service level agreement are likely to be important to the discussion.

A measure of service delivery performance associated with a service level. (See also “measure” and “service level.”)

A consolidated and standardized set of services and service levels that satisfy specific needs of a selected market or mission area. (See also “product line” and “service level.”)

A communication from a customer or end user that one or more specific instances of service delivery are desired. (See also “service agreement.”)
These requests are made within the context of a service agreement.
In cases where services are to be delivered continuously or periodically, some service requests may be explicitly identified in the service agreement itself.
In other cases, service requests that fall within the scope of a previously established service agreement are generated over time by customers or end users as their needs develop.

The complete set of requirements that affect service delivery and service system development. (See also “service system.”)
Service requirements include both technical and nontechnical requirements. Technical requirements are properties of the service to be delivered and the service system needed to enable delivery. Nontechnical requirements may include additional conditions, provisions, commitments, and terms identified by agreements, and regulations, as well as needed capabilities and conditions derived from business objectives.

An integrated and interdependent combination of component resources that satisfies service requirements. (See also “service system component” and “service requirements.”)
A service system encompasses everything required for service delivery, including work products, processes, facilities, tools, consumables, and human resources.
Note that a service system includes the people necessary to perform the service system’s processes. In contexts where end users perform some processes for service delivery to be accomplished, those end users are also part of the service system (at least for the duration of those interactions).
A complex service system may be divisible into multiple distinct delivery and support systems or subsystems. While these divisions and distinctions may be significant to the service provider organization, they may not be as meaningful to other stakeholders.

A resource required for a service system to successfully deliver services.
Some components can remain owned by a customer, end user, or third party before service delivery begins and after service delivery ends. (See also “customer” and “end user.”)
Some components can be transient resources that are part of the service system for a limited time (e.g., items that are under repair in a maintenance shop).
Components can include processes and people.
The word “component” can be used in place of “service system component” for brevity when the context makes the meaning clear.
The word “infrastructure” can be used to refer collectively to service system components that are tangible and essentially permanent. Depending on the context and type of service, infrastructure can include human resources.

A service system component that ceases to be available or becomes permanently changed by its use during the delivery of a service.
Fuel, office supplies, and disposable containers are examples of commonly used consumables. Particular types of services can have their own specialized consumables (e.g., a health care service may require medications or blood supplies).
People are not consumables, but their labor time is a consumable.

specific goal

A common understanding of guiding principles, including mission, objectives, expected behavior, values, and final outcomes, which are developed and used by a project or work group.

(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. (2) The study of approaches as in (1). (See also “hardware engineering,” and “systems engineering.”)

The process of preparing a package to be used in selecting a supplier. (See also “solicitation package.”)

A collection of formal documents that includes a description of the desired form of response from a potential supplier, the relevant statement of work for the supplier, and required provisions in the supplier agreement.

specific practice

A cause of a defect that is specific to some transient circumstance and is not an inherent part of a process. (See also “common cause of variation.”)

A required model component that describes the unique characteristics that must be present to satisfy the process area. (See also “capability level,” “generic goal,” “organization’s business objectives,” and “process area.”)

An expected model component that is considered important in achieving the associated specific goal. (See also “process area” and “specific goal.”)
The specific practices describe the activities expected to result in achievement of the specific goals of a process area.

schedule performance index

Service System Development (process area in CMMI-SVC)

Systems Security Engineering Capability Maturity Model

The state in which special causes of process variation have been removed and prevented from recurring so that only common causes of process variation of the process remain. (See also “capable process,” “common cause of variation,” “special cause of variation,” and “standard process.”)

A model structure wherein attaining the goals of a set of process areas establishes a maturity level; each level builds a foundation for subsequent levels. (See also “maturity level” and “process area.”)

A group or individual that is affected by or is in some way accountable for the outcome of an undertaking. (See also “customer” and “relevant stakeholder.”)
Stakeholders may include project or work group members, suppliers, customers, end users, and others.
This term has a special meaning in the CMMI Product Suite besides its common standard English meaning.

Formal requirements developed and used to prescribe consistent approaches to acquisition, development, or service.
Examples of standards include ISO/IEC standards, IEEE standards, and organizational standards.

An operational definition of the basic process that guides the establishment of a common process in an organization.
A standard process describes the fundamental process elements that are expected to be incorporated into any defined process. It also describes relationships (e.g., ordering, interfaces) among these process elements. (See also “defined process.”)

A description of work to be performed.

Analytic techniques that enable accomplishing an activity by quantifying parameters of the task (e.g., inputs, size, effort, and performance). (See also “statistical techniques” and “quantitative management.”)
This term is used in the high maturity process areas where the use of statistical and other quantitative techniques to improve understanding of project, work, and organizational processes is described.
Examples of non-statistical quantitative techniques include trend analysis, run charts, Pareto analysis, bar charts, radar charts, and data averaging.
The reason for using the compound term “statistical and other quantitative techniques” in CMMI is to acknowledge that while statistical techniques are expected, other quantitative techniques can also be used effectively.

Statistically based analysis of a process and measures of process performance, which identify common and special causes of variation in process performance and maintain process performance within limits. (See also “common cause of variation,” “special cause of variation,” and “statistical techniques.”)

Techniques adapted from the field of mathematical statistics used for activities such as characterizing process performance, understanding process variation, and predicting outcomes.
Examples of statistical techniques include sampling techniques, analysis of variance, chi-squared tests, and process control charts.

An informative model component that provides guidance for interpreting and implementing specific or generic practices.
Subpractices may be worded as if prescriptive, but they are actually meant only to provide ideas that can be useful for process improvement.

A process that is part of a larger process. (See also “process,” “process description,” and “process element.”)
A subprocess may or may not be further decomposed into more granular subprocesses or process elements. The terms “process,” “subprocess,” and “process element” form a hierarchy with “process” as the highest, most general term, “subprocesses” below it, and “process element” as the most specific. A subprocess can also be called a process element if it is not decomposed into further subprocesses.

(1) An entity delivering products or performing services being acquired. (2) An individual, partnership, company, corporation, association, or other entity having an agreement with an acquirer for the design, development, manufacture, maintenance, modification, or supply of items under the terms of an agreement. (See also “acquirer.”)

A documented agreement between the acquirer and supplier. (See also “supplier.”)
Supplier agreements are also known as contracts, licenses, and memoranda of agreement.

The processes used to ensure that a product or service remains operational.

Capability Maturity Model for Software or Software Capability Maturity Model

A set or arrangement of systems that results when independent and useful systems are integrated into a large system that delivers unique capabilities.

The interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a solution and to support that solution throughout its life. (See also “hardware engineering” and “software engineering.”)
This approach includes the definition of technical performance measures, the integration of engineering specialties toward the establishment of an architecture, and the definition of supporting lifecycle processes that balance cost, schedule, and performance objectives.

The act of making, altering, or adapting something for a particular end.
For example, a project or work group establishes its defined process by tailoring from the organization’s set of standard processes to meet its objectives, constraints, and environment. Likewise, a service provider tailors standard services for a particular service agreement.

Organizational guidelines that enable projects, work groups, and organizational functions to appropriately adapt standard processes for their use.
The organization’s set of standard processes is described at a general level that may not be directly usable to perform a process.
Tailoring guidelines aid those who establish the defined processes for project or work groups. Tailoring guidelines cover (1) selecting a standard process, (2) selecting an approved lifecycle model, and (3) tailoring the selected standard process and lifecycle model to fit project or work group needs. Tailoring guidelines describe what can and cannot be modified and identify process components that are candidates for modification.

A list of process areas and their corresponding capability levels that represent an objective for process improvement. (See also “achievement profile” and “capability level profile.”)

A sequence of target profiles that describes the path of process improvement to be followed by the organization. (See also “achievement profile,” “capability level profile,” and “target profile.”)

A group of people with complementary skills and expertise who work together to accomplish specified objectives.
A team establishes and maintains a process that identifies roles, responsibilities, and interfaces; is sufficiently precise to enable the team to measure, manage, and improve their work performance; and enables the team to make and defend their commitments.
Collectively, team members provide skills and advocacy appropriate to all aspects of their work (e.g., for the different phases of a work product’s life) and are responsible for accomplishing the specified objectives.
Not every project or work group member must belong to a team (e.g., a person staffed to accomplish a task that is largely self-contained). Thus, a large project or work group can consist of many teams as well as project staff not belonging to any team. A smaller project or work group can consist of only a single team (or a single individual).

A collection of items that can include the following if such information is appropriate to the type of product and product component (e.g., material and manufacturing requirements may not be useful for product components associated with software services or processes):
• Product architecture description
• Allocated requirements
• Product component descriptions
• Product related lifecycle process descriptions if not described as separate product components
• Key product characteristics
• Required physical characteristics and constraints
• Interface requirements
• Materials requirements (bills of material and material characteristics)
• Fabrication and manufacturing requirements (for both the original equipment manufacturer and field support)
• Verification criteria used to ensure requirements have been achieved
• Conditions of use (environments) and operating/usage scenarios, modes and states for operations, support, training, manufacturing, disposal, and verifications throughout the life of the product
• Rationale for decisions and characteristics (e.g., requirements, requirement allocations, design choices)

Characteristic of a process, product, or service, generally defined by a functional or technical requirement.
Examples of technical performance types include estimating accuracy, end-user functions, security functions, response time, component accuracy, maximum weight, minimum throughput, allowable range.

Precisely defined technical measure of a requirement, capability, or some combination of requirements and capabilities. (See also “measure.”)

Properties (i.e., attributes) of products or services to be acquired or developed.

A discernable association among two or more logical entities such as requirements, system elements, verifications, or tasks. (See also “bidirectional traceability” and “requirements traceability.”)

An evaluation of alternatives, based on criteria and systematic analysis, to select the best alternative for attaining determined objectives.

Characteristic of a process, product, or service, generally defined by a functional or technical requirement.
Examples of technical performance types include estimating accuracy, end-user functions, security functions, response time, component accuracy, maximum weight, minimum throughput, allowable range.
Examples of technical performance types include estimating accuracy, end-user functions, security functions, response time, component accuracy, maximum weight, minimum throughput, allowable range.
The learning options selected for each situation are based on an assessment of the need for training and the performance gap to be addressed.

Technical Solution (process area)

Testing of individual hardware or software units or groups of related units. (See also “acceptance testing.”)

Validation (process area)

Confirmation that the product or service, as provided (or as it will be provided), will fulfill its intended use.
In other words, validation ensures that “you built the right thing.” (See also “verification.”)

Verification (process area)

Confirmation that work products properly reflect the requirements specified for them.
In other words, verification ensures that “you built it right.” (See also “validation.”)

The establishment and maintenance of baselines and the identification of changes to baselines that make it possible to return to the previous baseline.
In some contexts, an individual work product may have its own baseline and a level of control less than formal configuration control may be sufficient.

work breakdown structure

An arrangement of work elements and their relationship to each other and to the end product or service.

A managed set of people and other assigned resources that delivers one or more products or services to a customer or end user. (See also “project.”)
A work group can be any organizational entity with a defined purpose, whether or not that entity appears on an organization chart. Work groups can appear at any level of an organization, can contain other work groups, and can span organizational boundaries.
A work group together with its work can be considered the same as a project if it has an intentionally limited lifetime.

A plan of activities and related resource allocations for a work group.
Work planning includes estimating the attributes of work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analyzing risks. Iterating through these activities can be necessary to establish the work plan.

A useful result of a process.
This result can include files, documents, products, parts of a product, services, process descriptions, specifications, and invoices. A key distinction between a work product and a product component is that a work product is not necessarily part of the end product. (See also “product” and “product component.”)
In CMMI models, the definition of “work product” includes services, however, the phrase “work products and services” is sometimes used to emphasize the inclusion of services in the discussion.

Characteristics of products, services, and tasks used to help in estimating work. These characteristics include items such as size, complexity, weight, form, fit, and function. They are typically used as one input to deriving other resource estimates (e.g., effort, cost, schedule).

When a set of interrelated resources for a work group is directed to develop or deliver one or more products or services for a customer or end user. (See also “work group.”)