开发手册 欢迎您!
软件开发者资料库

CMMI - 词汇表

CMMI术语表 - 通过简单易行的步骤学习SEI能力成熟度模型(CMMI)1,2,3,4和5级。能力成熟度水平的明确解释过程域成熟和不成熟的组织CMMI学科分阶段和连续表征。
ABCDEFGHIJK
LMNOPRSTUV
WXYZ






 

执行能力 :  CMMI模型过程域的一个共同特征,具有分阶段表示,将与确保项目和/或组织所需资源相关的通用实践分组.

验收标准 : 产品或产品组件必须满足的标准,以供用户,客户或其他授权实体接受.

验收测试 : 进行正式测试以使用户,客户或其他授权实体能够确定是否接受产品或产品组件.

成就概况 : 在连续表示中,一个过程域列表及其相应的能力等级,表示组织在逐步提升能力水平时每个过程域的进度.

获取  : 去;通过合同获得收购实体的任何离散行动或建议行动的过程,该行动将承诺投资以获得产品和服务.

收购策略 :  ;获取产品和服务的具体方法基于供应来源,采购方法,需求规格类型,合同或协议类型以及相关购置风险的考虑.

足够 :  CMMI中充分,适当且根据需要出现,以便各级管理人员和从业人员根据组织的业务目标解释具体和通用的目标和实践.例如,风险管理过程域的通用实践陈述与否; "为执行风险管理流程,开发工作产品和提供流程服务提供足够的资源."人数,必须监控风险的人等都可以满足.

高级实践 : 在连续表示中,能力级别为2或更高的所有特定实践.

协议/合同要求 : 与收购相关的所有技术和非技术要求.

分配的要求 : 要求在较低级别的架构元素或设计组件上征收更高级别要求的全部或部分性能和功能.

替代实践 : 一种替代CMMI模型中包含的一个或多个通用或特定实践的实践,可以实现与满足与模型实践相关的通用或特定目标的等效效果.替代做法不一定是一般性或特定做法的一对一替代.

评估 : 评估是由经过培训的专业团队使用评估参考模型作为确定优势和劣势的基础来检查一个或多个过程.

评估结果  : 去;评估结论,确定评估范围内最重要的问题,问题或机会.它至少包括基于有效观察的优点和缺点.

评估参与者 : 在评估期间参与提供信息的组织单位成员.

评估等级 : 如CMMI评估材料中所使用的,评估团队分配给(1)CMMI目标或过程域,(2)过程域的能力等级,或(3)组织单位的成熟度等级的值.评级是通过对所采用的评估方法制定定义的评级过程来确定的.

评估参考模型 : 在CMMI评估材料中使用的CMMI模型,评估团队将实施的过程活动与之相关联.

评估范围 : 评估边界的定义包括组织限制和CMMI模型限制.

评估团队负责人 : 领导评估活动并且满足评估方法定义的经验,知识和技能的资格标准的人.

适当的 : 见充足的定义.

根据需要 : 见充足的定义.

评估 : 评估是指组织为了过程改进而自行进行的评估.

过程变异的可分配原因 : 在CMMI中,术语"过程变异的特殊原因"用于代替"可分配的过程变化原因"以确保一致性.两个术语的定义相同.

审核 : 对工作产品或工作产品组进行独立检查,以确定是否符合要求.

 

基本措施 : 实体的独特属性或特征以及量化它的方法.

基本实践 : 在连续表示中,能力级别为1的所有特定实践.

基线 : 术语基线通常用于表示这样的参考点.基线是在开发生命周期中的适当点处系统的批准快照.基线为定义后续变更建立了正式基础.如果没有这条线或参考点,变化的概念就毫无意义.

业务目标 : 高级管理层制定的战略旨在确保组织的持续存在,并提高其盈利能力,市场份额以及影响组织成功的其他因素.

 

能力评估 : 由经过培训的专业团队进行评估,作为鉴别者选择供应商,进行合同监督或激励.评估用于帮助决策者做出更好的收购决策,提高分包商绩效,并为采购组织提供洞察力.

能力水平 : 在单个过程域内实现过程改进.能力水平由过程域的适当特定和通用实践定义.

能力水平概况 : 在连续表示中,过程区域列表及其相应的能力级别.当概要表示组织在推进能力水平的过程中每个过程域的进度时,该概要可能是成就概况.或者,当配置文件表示流程改进的目标时,配置文件可能是目标配置文件.

能力成熟度模型 : 能力成熟度模型(CMM)包含一个或多个学科的有效流程的基本要素.它还描述了从临时的,不成熟的流程到具有改进的质量和有效性的规范的成熟流程的渐进式改进路径.

有能力的流程 : 一个能够满足其指定产品质量,服务质量和过程绩效目标的过程.

原因分析 : 分析缺陷以确定其原因.

变更管理 : 明智地使用手段对产品或服务进行更改或建议更改.

CMMI评估定制 : 选择评估方法中的选项以用于特定实例.评估定制的目的是帮助组织将方法的应用与其业务目标保持一致.

CMMI模型组件 : 构成CMMI模型的任何主要架构元素. CMMI模型的一些主要元素包括特定实践,通用实践,特定目标,通用目标,过程域,功能级别和成熟度级别.

CMMI模型定制 : 使用CMMI模型的子集以使其适合于特定应用.模型定制的目的是帮助组织将模型的应用与其业务目标保持一致.

CMMI Product Suite : 该术语已用于完整的CMMI框架.

承诺执行 :  CMMI模型过程域的一个共同特征,具有分阶段表示,将与创建策略和确保赞助相关的一般实践分组.

过程变异的常见原因 : 由于流程组件之间的正常和预期交互而存在的流程变化.

运营概念 : 关于实体使用或运营方式的一般描述.

配置审核 : 进行审核以验证配置项是否符合指定的标准或要求.

配置基线 : 在产品或产品组件的生命周期中的特定时间正式指定的配置信息.配置基线以及来自这些基准的批准更改构成当前配置信息.

配置控制 : 配置管理的一个要素,包括评估,协调,批准或不批准,以及在正式建立配置标识后对配置项的更改实施.

配置控制板 : 一组人员负责评估,批准或拒绝对配置项目的建议更改,以及确保实施已批准的更改.

配置标识 : 配置管理的一个要素,包括选择产品的配置项,为它们分配唯一标识符,以及在技术文档中记录它们的功能和物理特性.

配置项

b> : 指定用于配置管理并在配置管理过程中视为单个实体的工作产品的聚合.

配置管理 : 应用技术和行政指导和监督的学科(1)识别和记录配置项的功能和物理特性,(2)控制对这些特征的变化,(3)记录和报告变更处理和实施状态,(4) )验证是否符合规定的要求. [IEEE Std 610.1990]

CMMI模型 : 由于CMMI框架可以根据使用它的组织的需求生成不同的模型,因此有多个CMMI模型.因此,短语"CMMI MODEL"可以是许多信息集合中的任何一个.短语"CMMI模型"是指可以从CMMI框架生成的一个,一些或整个可能模型集合.

配置状态记帐 : 去;配置管理的一个要素,包括记录和报告有效管理配置所需的信息.此信息包括已批准的配置标识列表,配置的建议更改状态以及已批准更改的实施状态.

连续表示 : 能力成熟度模型结构,其中能力级别提供在每个指定过程域内接近过程改进的建议顺序.

纠正措施 : 用于纠正某种情况,删除错误或调整条件的行为或行为.

COTS : 可以从商业供应商处购买的商品.

客户 : 客户是负责接受产品或授权付款的个人,项目,组织,团体等.客户在项目外部,但不一定在组织外部.当我们讨论需求收集或启发时,客户一词也可作为变量.

 

数据管理 : 共享和管理数据的原则,流程和系统.

缺陷密度 : 每单位产品尺寸的缺陷数量(例如,每1000行代码的问题报告).

定义过程 : 作为改进的一部分,应遵循一组明确的步骤.

派生措施 : 由两个或多个基本指标的数学函数得出的数据.

派生要求 : 客户要求中未明确说明的要求,但从上下文要求(例如,适用的标准,法律,政策,通用惯例和管理决策)推断(1),或(2)指定产品组件所需的要求.在产品或系统组件的分析和设计过程中也会出现衍生需求.

设计审核 : 对设计进行正式,文档化,全面和系统的检查,以评估设计要求和设计满足这些要求的能力,并找出问题并提出解决方案.

发展 : 整个CMMI中使用的开发意味着维护活动以及开发活动.经验表明,如果组织追求卓越的工程设计,最佳实践应该应用于开发和维护项目.

发展计划 : 指导,实施和控制一种或多种产品的设计和开发的计划.

指导实施 :  CMMI模型过程域的一个共同特征,具有分阶段表示,将与管理过程绩效,管理其工作产品的完整性以及涉及相关利益相关者相关的一般实践分组.

纪律放大 : 为特定学科(例如,系统工程或软件工程)解释模型信息提供指导的模型组件称为"学科放大".必要时,将学科扩充添加到其他模型组件中.这些很容易找到,因为它们出现在页面的右侧,并有一个标题表明它们所处理的规则(例如,"For Software Engineering").

文件 : 文档是数据的集合,无论其记录的媒介如何.它通常具有永久性,可由人或机器读取.文件包括纸质和电子文件.

 

企业 : 企业用于指代由许多不同地点的客户组成的非常大的公司.

进入标准 : 在努力成功开始之前必须存在的状态.

等效分期 : 等效分段是一个目标分段,使用定义的连续表示创建,以便可以将使用目标分段的结果与分阶段表示的成熟度级别进行比较.

退出标准 : 在努力成功结束之前必须存在的状态.

预期的CMMI组件 :  CMMI组件,解释可以采取哪些措施来满足所需的CMMI组件.模型用户可以明确地实现预期的组件,或者为这些组件实现等效的替代实践.具体和通用做法是预期的模型组件

 

查找 : 见评估结果.

正式评估过程 : 在决策分析和解决方案过程中,请参阅介绍性说明中"正式评估过程"的定义.

功能分析 : 检查定义的函数,以识别完成该函数所需的所有子函数;识别功能关系和接口(内部和外部)并在功能架构中捕获这些;并向下流动上层性能要求并将这些要求分配给较低级别的子功能.

功能架构 : 功能的分层排列,它们的内部和外部(聚合本身外部)功能接口和外部物理接口,它们各自的功能和性能要求,以及它们的设计约束.

 

通用目标 :  GENERIC GOALS被称为"通用",因为相同的目标陈述出现在多个过程域中.在分阶段表示中,每个过程域只有一个通用目标.在过程域中实现通用目标意味着改进对规划和实施与该过程域相关的过程的控制,从而指示这些过程是否可能是有效的,可重复的和持久的.通用目标是必需的模型组件,用于评估以确定是否满足过程域.

通用实践 : 通用做法提供制度化,以确保与过程域相关的过程有效,可重复和持久.通用实践按通用目标和通用功能进行分类,是CMMI模型中的预期组件. (只有通用实践标题,声明和详细说明出现在过程域中.)

通用实践阐述 : 在具体实践之后,通用实践标题和陈述似乎适用于过程域.在每个通用实践声明之后,详细说明可能以纯文本形式出现,标题为"精化". GENERIC PRACTICE ELABORATION提供有关如何为过程域解释通用实践的信息.如果没有详细说明,那么通用实践的应用是显而易见的.

目标 :  "目标"是必需的CMMI组件,可以是通用目标或特定目标.当您在CMMI模型中看到"目标"一词时,它总是指模型组件(例如,通用目标,特定目标).

 

不完整的流程 : 未执行或仅部分执行的过程(也称为功能级别0).过程域的一个或多个具体目标不满足.

独立组 : 在流程和产品质量保证流程领域,请参阅介绍性说明中对"独立组"的讨论.

信息性CMMI组件 :  CMMI组件,帮助建模用户了解模型的必需组件和预期组件.这些组件可能包含示例,详细说明或其他有用信息.子实践,笔记,参考文献,目标标题,实践标题,来源,典型的工作产品,学科扩展和通用实践阐述是信息模型的组成部分.

制度化 : 作为企业文化的一部分,组织经常遵循的根深蒂固的经营方式.

集成产品和流程开发 : 系统化的产品开发方法,在整个产品生命周期内实现相关利益相关方的及时协作,以更好地满足客户需求.

整合团队 : 一群具有互补技能和专业知识的人,他们致力于及时协作提供特定的工作产品.集成的团队成员提供适合工作产品所有阶段的技能和倡导,并共同负责按规定交付工作产品.一个整合的团队应该包括与工作产品成功相关的组织,学科和职能部门的授权代表.

界面控制 : 在配置管理中,(1)识别与一个或多个组织提供的两个或多个配置项的接口相关的所有功能和物理特征,以及(2)确保先前评估和批准对这些特性的建议更改的过程实施. [IEEE 828-1983].

       

首席评估师 : 正如CMMI产品套件中所使用的那样,已获得授权机构认可的人员作为特定评估方法的评估团队负责人.

生命周期模型 : 将产品的生命周期划分为指导项目从确定客户需求到产品退役的阶段.

 

经理 : 项目经理是负责规划,指导,控制,构建和激励项目的人员.他或她可以为在其职责范围内执行项目任务或活动的人员提供技术和行政指导和控制.项目经理最终对客户负责.

成熟度 : 在预定义的一组过程域中的过程改进程度,其中达到了集合中的所有目标.

协议备忘录 : 约束两方或多方之间的理解或协议文件.

 

自然界限 : 过程绩效测量反映的固有过程,有时被称为"过程的声音".诸如控制图,置信区间和预测区间之类的技术用于确定变化是由于常见原因(即,过程是可预测的还是"稳定的"),或者是由于某些特殊原因可以并且应该被识别和已删除.

非发展项目 : 在收购或开发过程中目前使用之前开发的供应项目.此类项目可能需要进行微小修改以满足其当前预期用途的要求.

非技术要求 : 影响产品或服务获取方式的合同条款,承诺,条件和条款.示例包括要交付的产品,交付的商业现货(COTS)非开发项目(NDI)的数据权利,交付日期和具有退出标准的里程碑.其他非技术要求包括培训要求,站点要求和部署计划.

 

目标 : 在日常的常识中,术语"目标"用于CMMI;这是我们的目标或目标.

客观证据 : 用于CMMI评估材料,定性或定量信息,记录或与项目或服务的特征或过程元素的存在和实施有关的事实陈述,其基于观察,测量或测试,并且可以验证.

客观评估 : 根据审核人最小化主观性和偏见的标准审核活动和工作产品.客观评估的一个例子是通过独立的质量保证职能对要求,标准或程序进行审计.

观察 : 在CMMI评估材料中使用的书面记录,代表评估团队成员对评估数据收集活动中看到或听到的信息的理解.书面记录可以采用声明的形式,也可以采用其他形式,只要保留信息内容即可.

操作概念 : 关于实体使用或运营方式的一般描述.

运营情景 : 对想象的事件序列的描述,包括产品与其环境和用户的交互,以及其产品组件之间的交互.操作方案用于评估系统的要求和设计,以及验证和验证系统.

优化过程 : 基于对过程中固有变异的常见原因的理解而改进的定量管理过程.这一流程侧重于通过渐进式和创新性改进不断改进流程绩效范围.

组织 : 组织是一种人们共同管理一个或多个项目的结构,其项目共享一名高级管理人员并按照相同的政策运作.

组织的业务目标 : 高级管理层制定的策略,以确保组织的持续存在,并提高其盈利能力,市场份额以及影响组织成功的其他因素.

组织成熟度 : 组织明确且一致地部署记录,管理,测量,控制和持续改进的流程的程度.组织期限可以通过评估来衡量.

组织政策 : 高级管理层通常建立的指导原则,由组织采用以影响和确定决策.

组织单位 : 作为评估主体的组织的一部分(也称为评估的组织范围).组织单元部署一个或多个具有连贯的过程上下文并在一组连贯的业务目标内运行的过程.组织单位通常是较大组织的一部分,但在小型组织中,组织单位可能是整个组织.

外包 : 通过合同获得承诺投资以获得产品和服务的收购实体的任何离散行动或建议行动的过程.

 

同行评审 : 同行进行的审查,以找出交付品中的缺陷.

性能参数 : 用于指导和控制渐进发展的有效性措施和其他关键措施.

执行过程 : 使用已识别的输入工作产品(也称为能力级别1)完成所需工作以生成已识别的输出工作产品的过程.过程域的具体目标得到满足.

计划过程 : 由描述和计划记录的过程.应该协调描述和计划,计划应包括标准,要求,目标,资源,任务等.

流程 : 人们用来开发和维护系统及相关产品的一系列活动,方法,实践和转换.

流程行动计划 : 在组织过程焦点过程域中,请参阅介绍性说明中"过程操作计划"的定义.

流程操作团队 : 一个团队,负责为流程改进行动计划中记录的组织制定和实施流程改进活动.

流程和技术改进 :  ;在组织创新和部署过程中,请参阅介绍性说明中对"过程和技术改进"的讨论.

过程域 :  A Process area is a cluster of related practices in an area that, when performed collectively, satisfy a set of goals considered important for making significant improvement in that area. All CMMI process areas are common to both continuous and staged representations. In the staged representation, process areas are organized by maturity levels.

Process asset  :  Anything that the organization considers useful in attaining the goals of a process area.

Process asset library  :  A collection of process asset holdings that can be used by an organization or project.

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 context  :  The set of factors, documented in the appraisal input, that influences the judgement and comparability of appraisal ratings. These include, but are not limited to, the size of the organizational unit to be appraised; the demographics of the organizational unit; the application discipline of the products or services; the size, criticality, and complexity of the products or services; and the quality characteristics of the products or services.

Process definition  :  The act of defining and describing a process. The result of process definition is a process description.

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

Process element  :  The fundamental unit of a process. A process may be defined in terms of sub-processes or process elements. A sub-process can be further decomposed; a process element cannot. Each process element covers a closely related set of activities (for example, 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.

Process group  :  A collection of specialists that facilitate the definition, maintenance, and improvement of the process(es) used by the organization.

Process improvement  :  A program of activities designed to improve the 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 characteristics (e.g., quality, performance, conformance to standards, etc.) or in the way in which the process is executed (e.g., elimination of redundant process steps, combining process steps, improving cycle time, etc.)

Process-improvement plan  :  In the Organizational Process Focus process area, see the definition of "process improvement plan" in the introductory notes.

Process measurement  :  The set of definitions, methods, and activities used to take measurements of a process and its resulting products for the purpose of characterizing and understanding the process.

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 level, the process owner is the person (or team) responsible for the description of the defined process. A process may therefore have multiple owners at different levels of responsibility.

Process performance  :  A measure of actual results achieved by following a process. It is characterized by both process measures (e.g., effort, cycle time, and defect removal efficiency) and product measures (e.g., reliability, defect density, and response time).

Process performance baseline  :  A documented characterization of the actual results achieved by following a process, which is used as a benchmark for comparing actual process performance against expected process performance.

Process performance model  :  A description of the relationships among attributes of a process and its work products that are developed from historical process performance data and calibrated using collected process and product measures from the project and which are used to predict results to be achieved by following a process.

Process tailoring  :  To make, alter, or adapt a process description for a particular end. For example, a project tailors its defined process from the organization’s set of standard processes to meet the objectives, constraints, and environment of the project.

Product  :  A product may be thought of as any tangible output or service that is the result of following a process and is intended for delivery to a customer or end user. A product can also be any work product that is delivered to the customer according to contract.

Product component  :  Product components are generally lower-level components of the product and are integrated to "build" the product. Product components may be a part of the product delivered to the customer or serve in the manufacture or use of the product. For example, for those companies that manufacture mobile phone batteries, the mobile phone battery is a product. For those companies that build and deliver mobile phones, the battery is a product component.

Product baseline  :  In configuration management, the initial approved technical data package (including, for software, the source code listing) defining a configuration item during the production, operation, maintenance, and logistic support of its life cycle.

Product-component requirements  :  Product-component requirements provide a complete specification of a product component, including fit, form, function, performance, and any other requirement.

Product life cycle  :  A work product is any artifact produced by a life-cycle process and can also be referred to as a life-cycle work product. Life-cycle work products can include Requirements specifications, Interface specifications, Architecture specifications, Project plans, Design documents, Unit test plans, Integration and system test plans, A process such as a manufacturing product assembly process.

Project  :  A project is a managed set of interrelated resources that delivers one or more products to a customer or end user. The set of resources has a definite beginning and end and operates according to a plan.

Product line  :  A group of products sharing a common, managed set of features that satisfy specific needs of a selected market or mission.

Product-related life-cycle processes  :  Processes associated with a product throughout one or more phases of its life (i.e., from conception through disposal), such as the manufacturing and support processes.

Product requirements  :  A refinement of the customer requirements into the developers’ language, making implicit requirements into explicit derived requirements.

Program  :  (1) A project. (2) A collection of related projects and the infrastructure that supports them, including objectives, methods, activities, plans, and success measures.

Project manager  :  A project manager is the person responsible for planning, directing, controlling, structuring, and motivating the project. He or she may provide both technical and administrative direction and control to those performing project tasks or activities within his or her area of responsibility. The project manager is ultimately responsible to the customer. The project manager takes on different roles and responsibilities as the size, diversity, and complexity of the project changes.

Project progress and performance  :  What a project achieves with respect to implementing project plans, including effort, cost, schedule, and technical performance.

Project’s defined process  :  In the Integrated Project Management process area, see the definition of "Project’s defined process" in the introductory notes and in the Establish the Projects Defined Process specific practice.

Prototype  :  A preliminary type, form, or instance of a product or product component that serves as a model for later stages or for the final, complete version of the product.

Quality  :  The ability of a set of inherent characteristics of a product, product component, or process to fulfill requirements of customers.

Quality assurance  :  A planned and systematic means for assuring management that defined standards, practices, procedures, and methods of the process are applied.

Quality control  :  The operational techniques and activities that are used to fulfill requirements for quality.

Quantitative objective  :  Desired target value expressed as quantitative measures.

Quantitatively managed process  :  A defined process that is controlled using statistical and other quantitative techniques. The product quality, service quality, and process performance attributes are measurable and controlled throughout the project.

Reference mode  :  A model that is used as a benchmark for measuring some attribute.

Relevant stakeholder  :  A relevant stakeholder is used to designate a stakeholder that is identified for involvement in specified activities and is included in an appropriate plan such as the project plan.

Required CMMI components  :  CMMI components that are essential to achieving process improvement in a given process area. These components are used in appraisals to determine process capability. Specific goals and generic goals are required model components.

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 or product component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2).

Requirements analysis  :  The determination of product-specific performance and functional characteristics based on analyses of customer needs, expectations, and constraints; operational concept; projected utilization environments for people, products, and processes; and measures of effectiveness.

Requirements elicitation  :  Using systematic techniques, like 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, including both technical and non-technical requirements as well as those requirements levied on the project by the organization.

Requirements traceability  :  The evidence of an association between a requirement and its source requirement, its implementation, and its verification.

Return on investment  :  The ratio of revenue from output (product) 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 to seek out probable or realistic risks in achieving objectives.

Risk management  :  An organized, analytic process to identify what might cause harm or loss (identify risks), assess and quantify the identified risks, and to develop and, if needed, implement an appropriate approach to prevent or handle risk causes that could result in significant harm or loss.

Risk management strategy  :  An organized, technical approach to identify what might cause harm or loss (identify risks), assess and quantify the identified risks, and to develop and if needed implement an appropriate approach to prevent or handle risk causes that could result in significant harm or loss. Typically, risk management is performed for project, organization, or product-developing organizational units.

Root cause  :  A root cause is a source of a defect such that if it is removed, the defect is decreased or removed.

Senior manager  :  The term senior manager as it is used in CMMI refers to a management role at a high enough level in an organization that the primary focus of the person is the long-term health and success of the organization rather than the short-term project and contractual concerns and pressures. A senior manager may be responsible for the oversight of a program that may contain many projects that are managed by project managers.

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

Solicitation  :  The process of preparing a solicitation package and selecting a supplier (contractor).

Solicitation package  :  A formal document delineating technical and non-technical requirements that is used to request offers on invitations for bids (bids) and requests for proposal (proposals), or to request statements of capabilities and price quotations (quotes). It is otherwise used as a basis for selecting a supply source or sources to provide products or services.

Special cause of process variation  :  A cause of a defect that is specific to some transient circumstance and not an inherent part of a process.

Specific goal  :  SPECIFIC GOALS apply to a process area and address the unique characteristics that describe what must be implemented to satisfy the process area. Specific goals are required model components and are used in appraisals to help determine whether a process area is satisfied.

Specific practice  :  A SPECIFIC PRACTICE is an activity that is considered important in achieving the associated specific goal. The specific practices describe the activities expected to result in achievement of the specific goals of a process area. Specific practices are expected model components.

Stable process  :  The state in which all special causes of process variation have been removed and prevented from recurring so that only the common causes of process variation of the process remain.

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.

Stakeholder  :  A stakeholder is a group or individual that is affected by the outcome of a project or can affect the activities or output of the project.

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 the relationships (e.g., ordering and interfaces) between these process elements.

Statement of work  :  A description of contracted work required to complete a project.

Statistical predictability  :  The performance of a quantitative process that is controlled using statistical and other quantitative techniques.

Statistical process control  :  Statistically based analysis of a process and measurements of process performance, which will identify common and special causes of variation in the process performance, and maintain process performance within limits.

Statistical techniques  :  An analytic technique that employs statistical methods (e.g., statistical process control, confidence intervals, prediction intervals).

Statistically managed process  :  A process that is managed by a statistically based technique in which processes are analyzed, special causes of process variation are identified, and performance is contained within well-defined limits.

Strength  :  As used in CMMI appraisal materials, an exemplary or noteworthy implementation of a CMMI model practice.

Sub-process  :  A process that is part of a larger process.

Supplier  :  (1) An entity delivering products or performing services being acquired. (2) An individual, partnership, company, corporation, association, or other service having an agreement (contract) with an acquire for the design, development, manufacture, maintenance, modification, or supply of items under the terms of an agreement (contract).

Sustainment  :  The processes used to ensure that a product can be utilized operationally by its end users or customers. Sustainment ensures that maintenance is done such that the product is in an operable condition whether the product is in use or not by customers or end users.

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 product solution and support that solution throughout the products life. This includes the definition of technical performance measures, the integration of engineering specialities towards the establishment of a product architecture, and the definition of supporting life-cycle processes that balance cost, performance, and schedule objectives.

Tailoring guidelines  :  Tailoring a process makes, alters, or adapts process descriptions, normally described at the organizational level, for use on a particular project. For most organizations, one organizational process definition cannot or will not be followed 100% for all of the projects. Some adaptation is normally needed. Tailoring guidelines then describe what can and cannot be modified and identify process components that are allowable candidates for modification.

Target profile  :  In the continuous representation, a list of process areas and their corresponding capability levels that represent an objective for process improvement.

Target staging  :  In the continuous representation, a sequence of target profiles that describes the path of process improvement to be followed by the organization.

Technical data package  :  A collection of items that may include the following if such information is appropriate to the type of product and product component.

Technical requirements  :  Properties (attributes) of products or services to be acquired or developed.

Test procedure  :  Detailed instructions for the setup, execution, and evaluation of results for a given test.

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

Training  :  In the Organizational Training process area, see the definition of .training. in the introductory notes.

Unit testing  :  Testing of individual hardware or software units or groups of related units.

Validation  :  Validation demonstrates that the product, as provided, (or as it will be provided) will fulfill its intended use in the operational environment. Validation assures that "You built the right thing."

Verification  :  Verification includes verification of the product and intermediate work products against all selected requirements, including customer, product, and product component requirements. Verification is inherently an incremental process. It begins with the verification of the requirements, progresses through the verification of the evolving work products, and culminates in the verification of the completed product. Verification addresses whether the work product properly reflects the specified requirements. Verification assures "You built it right."

Verifying implementation  :  A common feature of CMMI model process areas with a staged representation that groups the generic practices related to review by higher level management, and objective evaluation of conformance to process descriptions, procedures, and standards.

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.

Weakness  :  As used in CMMI appraisal materials, the ineffective, or lack of, implementation of one or more CMMI model practices.

Work breakdown structure  :  An arrangement of work elements and their relationship to each other and to the end product.

Work product  :  The term WORK PRODUCT is used throughout the CMMI Product Suite to mean any artifact produced by a process. These artifacts can include files, documents, parts of the product, services, processes, specifications, and invoices. Examples of processes to be considered as work products include a manufacturing process, a training process, and a disposal process for the product. A key distinction between a WORK PRODUCT and a product component is that a work product need not be engineered or part of the end product.

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