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.