Appendix D. Glossary
The glossary defines the basic terms used in CMMI models. Glossary entries are typically multiple-word terms consisting of a noun and one or more restrictive modifiers. (There are some exceptions to this rule that account for one-word terms in the glossary.)
The CMMI glossary of terms is not a required, expected, or informative component of CMMI models. Interpret the terms in the glossary in the context of the model component in which they appear.
To formulate definitions appropriate for CMMI, we consulted multiple sources. We first consulted the Merriam-Webster Online dictionary (www.merriam-webster.com/). We also consulted other standards as needed, including the following:
• ISO 9000 [ISO 2005a]
• ISO/IEC 12207 [ISO 2008a]
• ISO/IEC 15504 [ISO 2006a]
• ISO/IEC 15288 [ISO 2008b]
• ISO/IEC 15939 [ISO 2007]
• ISO 20000-1 [ISO 2005b]
• IEEE [IEEE 1991]
• CMM for Software (SW-CMM) V1.1
• EIA 632 [EIA 2003]
• SA-CMM [SEI 2002]
• People CMM (P-CMM) [Curtis 2009]
• CobiT v. 4.0 [IT Governance 2005]
• ITIL V3 (Service Improvement, Service Design, Service Operation, Service Strategy, and Service Transition) [Office of Government Commerce 2007]
We developed the glossary recognizing the importance of using terminology that all model users can understand. We also recognized that words and terms can have different meanings in different contexts and environments. The glossary in CMMI models is designed to document the meanings of words and terms that should have the widest use and understanding by users of CMMI products.
Even though the term “product” includes services as well as products and the term “service” is defined as a type of product, many of the terms in the glossary contain both the words “product” and “service” to emphasize that CMMI applies to both products and services.
Every glossary entry has two to three components. There is always a term and always a definition. Sometimes additional notes are provided.
The definition appears first in a type size similar to the term listed. Glossary notes follow the definition and are in a smaller type size.
acceptance criteria The criteria that a deliverable must satisfy to be accepted by a user, customer, or other authorized entity. (See also “deliverable.”)
acceptance testing Formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a deliverable. (See also “unit testing.”)
achievement profile 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.”)
acquirer The stakeholder that acquires or procures a product or service from a supplier. (See also “stakeholder.”)
acquisition The process of obtaining products or services through supplier agreements. (See also “supplier agreement.”)
acquisition strategy 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.
addition 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.
allocated requirement 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.
appraisal 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.
appraisal findings 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.
appraisal participants Members of the organizational unit who participate in providing information during an appraisal.
appraisal rating 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.
appraisal reference model 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.
appraisal scope 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.
architecture 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.”)
audit 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.
baseline 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.”)
base measure 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.
bidirectional traceability 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.”)
business objectives (See “organization’s business objectives.”)
capability level 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.
capability level profile 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.
capability maturity model 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.
capable process A process that can satisfy its specified product quality, service quality, and process performance objectives. (See also “stable process” and “standard process.”)
causal analysis The analysis of outcomes to determine their causes.
change management Judicious use of means to effect a change, or a proposed change, to a product or service. (See also “configuration management.”)
CMMI Framework 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.
CMMI model A model generated from the CMMI Framework. (See also “CMMI Framework” and “CMMI Product Suite.”)
CMMI model component 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.
CMMI Product Suite 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.
commercial off-the-shelf Items that can be purchased from a commercial supplier.
common cause of variation The variation of a process that exists because of normal and expected interactions among components of a process. (See also “special cause of variation.”)
configuration audit 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.”)
configuration baseline 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.
configuration control 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.”)
configuration control board 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.”
configuration identification 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.”)
configuration item 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.”)
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.”)
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.
constellation 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).
continuous representation 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.”)
contractor (See “supplier.”)
contractual requirements 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.
corrective action Acts or deeds used to remedy a situation or remove an error.
customer 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.”)
customer requirement 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.”)
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.
data management 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.
defect density Number of defects per unit of product size.
An example is the number of problem reports per thousand lines of code.
defined process 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.”)
definition of required functionality and quality attributes 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.
deliverable 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.
delivery environment 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.
derived measure Measure that is defined as a function of two or more values of base measures. (See also “base measure.”)
derived requirements 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.”)
design review 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.
development To create a product or service system by deliberate effort.
In some contexts, development can include the maintenance of the developed product.
document 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.
end user 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.”)
enterprise The full composition of a company. (See also “organization.”)
A company can consist of many organizations in many locations with different customers.
entry criteria States of being that must be present before an effort can begin successfully.
equivalent staging 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.
establish and maintain 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.
example work product An informative model component that provides sample outputs from a specific practice.
executive (See “senior manager.”)
exit criteria States of being that must be present before an effort can end successfully.
expected CMMI components 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.
findings (See “appraisal findings.”)
formal evaluation process A structured approach to evaluating alternative solutions against established criteria to determine a recommended solution to address an issue.
framework (See “CMMI Framework.”)
functional analysis 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.”)
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.”)
generic goal A required model component that describes characteristics that must be present to institutionalize processes that implement a process area. (See also “institutionalization.”)
generic practice 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.
generic practice elaboration 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.)
hardware engineering 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.
higher level management 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.
incomplete process 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.
informative CMMI components 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.
institutionalization The ingrained way of doing business that an organization follows routinely as part of its corporate culture.
interface control 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.”)
lifecycle model A partitioning of the life of a product, service, project, work group, or set of work activities into phases.
managed process 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.”)
manager 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.
maturity level 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.”)
measure (noun) 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.
measurement 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.
measurement result A value determined by performing a measurement. (See also “measurement.”)
memorandum of agreement Binding document of understanding or agreement between two or more parties.
A memorandum of agreement is also known as a “memorandum of understanding.”
natural bounds 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.”)
nondevelopmental item 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.
nontechnical requirements 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.
objectively evaluate 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.
operational concept A general description of the way in which an entity is used or operates.
An operational concept is also known as “concept of operations.”
operational scenario 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.
organization 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.”)
organizational maturity 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.
organizational policy A guiding principle typically established by senior management that is adopted by an organization to influence and determine decisions.
organizational process assets Artifacts that relate to describing, implementing, and improving processes.
Examples of these artifacts include policies, measurement descriptions, process descriptions and 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.”)
organization’s business objectives 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.”)
organization’s measurement repository 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.
organization’s process asset library 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.
organization’s set of standard processes 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.”)
outsourcing (See “acquisition.”)
peer review 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.”
performance parameters The measures of effectiveness and other key measures used to guide and control progressive development.
performed process A process that accomplishes the needed work to produce work products; the specific goals of the process area are satisfied.
planned process 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.
policy (See “organizational policy.”)
process 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.
process action plan A plan, usually resulting from appraisals, that documents how specific improvements targeting the weaknesses uncovered by an appraisal will be implemented.
process action team A team that has the responsibility to develop and implement process improvement activities for an organization as documented in a process action plan.
process and technology improvements Incremental and innovative improvements to processes and to process, product, or service technologies.
process architecture (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.
process area 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.
process asset Anything the organization considers useful in attaining the goals of a process area. (See also “organizational process assets.”)
process asset library A collection of process asset holdings that can be used by an organization, project, or work group. (See also “organization’s process asset library.”)
process attribute A measurable characteristic of process capability applicable to any process.
process capability The range of expected results that can be achieved by following a process.
process definition The act of defining and describing a process.
The result of process definition is a process description. (See also “process description.”)
process description 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.
process element 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.
process group A collection of specialists who facilitate the definition, maintenance, and improvement of processes used by the organization.
process improvement A program of activities designed to improve the process performance and maturity of the organization’s processes, and the results of such a program.
process improvement objectives 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.”)
process improvement plan 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.
process measurement 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.”)
process owner 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.”)
process performance 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).
process performance baseline 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.
process performance model 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.
process tailoring 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.”)
product 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.”)
product baseline 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.
product component 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.
product component requirements A complete specification of a product or service component, including fit, form, function, performance, and any other requirement.
product lifecycle 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.
product line 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.
product related lifecycle processes 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.
product requirements 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.
product suite (See “CMMI Product Suite.”)
project A managed set of interrelated activities and resources, including people, that delivers one or more products or services to a customer or end user.
A project has an intended beginning (i.e., project startup) and end. Projects typically operate according to a plan. Such a plan is frequently documented and specifies what is to be delivered or implemented, the resources and funds to be used, the work to be done, and a schedule for doing the work. A project can be composed of projects. (See also “project startup.”)
In some contexts, the term “program” is used to refer to a project.
project plan 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.
project progress and performance What a project achieves with respect to implementing project plans, including effort, cost, schedule, and technical performance. (See also “technical performance.”)
project startup 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.”)
prototype 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 The degree to which a set of inherent characteristics fulfills requirements.
quality and process performance objectives Quantitative objectives and requirements for product quality, service quality, and process performance.
Quantitative process performance objectives include quality; however, to emphasize the importance of quality in the CMMI Product Suite, the phrase “quality and process performance objectives” is used. “Process performance objectives” are referenced in maturity level 3; the term “quality and process performance objectives” implies the use of quantitative data and is only used in maturity levels 4 and 5.
quality assurance A planned and systematic means for assuring management that the defined standards, practices, procedures, and methods of the process are applied.
quality attribute A property of a product or service by which its quality will be judged by relevant stakeholders. Quality attributes are characterizable by some appropriate measure.
Quality attributes are non-functional, such as timeliness, throughput, responsiveness, security, modifiability, reliability, and usability. They have a significant influence on the architecture.
quality control The operational techniques and activities that are used to fulfill requirements for quality. (See also “quality assurance.”)
quantitative management Managing a project or work group using statistical and other quantitative techniques to build an understanding of the performance or predicted performance of processes in comparison to the project’s or work group’s quality and process performance objectives, and identifying corrective action that may need to be taken. (See also “statistical techniques.”)
Statistical techniques used in quantitative management include analysis, creation, or use of process performance models; analysis, creation, or use of process performance baselines; use of control charts; analysis of variance, regression analysis; and use of confidence intervals or prediction intervals, sensitivity analysis, simulations, and tests of hypotheses.
quantitative objective Desired target value expressed using quantitative measures. (See also “measure,” “process improvement objectives,” and “quality and process performance objectives.”)
quantitatively managed (See “quantitative management.”)
reference model A model that is used as a benchmark for measuring an attribute.
relevant stakeholder A stakeholder that is identified for involvement in specified activities and is included in a plan. (See also “stakeholder.”)
representation 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.
required CMMI components 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.
requirement (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.”)
requirements analysis 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.”)
requirements elicitation Using systematic techniques such as prototypes and structured surveys to proactively identify and document customer and end-user needs.
requirements management 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.”)
requirements traceability A discernable association between requirements and related requirements, implementations, and verifications. (See also “bidirectional traceability” and “traceability.”)
return on investment 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.
risk analysis The evaluation, classification, and prioritization of risks.
risk identification An organized, thorough approach used to seek out probable or realistic risks in achieving objectives.
risk management 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.
senior manager 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.
service 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.
service agreement 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).
service catalog 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).
service incident 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.
service level A defined magnitude, degree, or quality of service delivery performance. (See also “service” and “service level measure.”)
service level agreement 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.
service level measure A measure of service delivery performance associated with a service level. (See also “measure” and “service level.”)
service line 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.”)
service request 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.
service requirements 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.
service system 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.
service system component 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.
service system consumable 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.
shared vision 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.
software engineering (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.”)
solicitation The process of preparing a package to be used in selecting a supplier. (See also “solicitation package.”)
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.
special cause of variation 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.”)
specific goal 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.”)
specific practice 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.
stable process 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.”)
staged representation 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.”)
stakeholder 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.
standard (noun) 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.
standard process 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.”)
statement of work A description of work to be performed.
statistical and other quantitative techniques 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.
statistical process control 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.”)
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.
subpractice 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.
subprocess 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.
supplier (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.”)
supplier agreement A documented agreement between the acquirer and supplier. (See also “supplier.”)
Supplier agreements are also known as contracts, licenses, and memoranda of agreement.
sustainment The processes used to ensure that a product or service remains operational.
system of systems A set or arrangement of systems that results when independent and useful systems are integrated into a large system that delivers unique capabilities.
systems engineering 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.
tailoring 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.
tailoring guidelines 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.
target profile 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.”)
Target profiles are only available when using the continuous representation.
target staging 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.”)
Target staging is only available when using the continuous representation.
team 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).
technical data package 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)
technical performance 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.
technical performance measure Precisely defined technical measure of a requirement, capability, or some combination of requirements and capabilities. (See also “measure.”)
technical requirements Properties (i.e., attributes) of products or services to be acquired or developed.
traceability A discernable association among two or more logical entities such as requirements, system elements, verifications, or tasks. (See also “bidirectional traceability” and “requirements traceability.”)
trade study An evaluation of alternatives, based on criteria and systematic analysis, to select the best alternative for attaining determined objectives.
training Formal and informal learning options.
These learning options can include classroom training, informal mentoring, web-based training, guided self study, and formalized on-the-job training programs.
The learning options selected for each situation are based on an assessment of the need for training and the performance gap to be addressed.
unit testing Testing of individual hardware or software units or groups of related units. (See also “acceptance testing.”)
validation 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 Confirmation that work products properly reflect the requirements specified for them.
In other words, verification ensures that “you built it right.” (See also “validation.”)
version control 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 (WBS) An arrangement of work elements and their relationship to each other and to the end product or service.
work group 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.
work plan 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.
work product 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.
work product and task attributes 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).
work startup 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.”)