-
CMMI
中英文术语对照表
1
标准名词术语
1 AT
Assessment Team
评审小组
2 ATM Assessment Team Member
评审小组成员
3 BA
Baseline Assessment
基线评审
4 CAR Causal Analysis and Resolution
原因分析与决策
5 CBA
CMM-Based Appraisal
基于
CMM
的评价
6
CBA-IPI
CMM-Based Appraisal
for
Internal
Process Improvement
为内部过程改进而进
行
的基于
CMM
的评价（通常
称为
CMM
评审）
7 CC Configuration Controller
配置管理员
8 CF Common
Feature
公共特性
9
CFPS Certified Function Point Specialist
注册功能点专家
10 CI
Configuration Item
配置项
11 CM Configuration Management
配置管理
12 CMM
Capability Maturity Model
能力成熟度模型
13 CMMI
Capability Maturity Model Integration
能力成熟度集成模型
14 COTS
Commerce off the shelf
商业现货供应
15 DAR
Decision Analysis and Resolution
决策分析与制定
16 DBD
Database Design
数据库设计
17 DD Detailed Design
详细设计
18 DP Data
Provider
数据提供者
19
DR Derived Requirement
派生需求
20 EPG Engineering Process Group
工程过程小组
21 FP
Function Point
功能点
22 FPA Function Point Analysis
功能点分析
23 FR
Functional Requirement
功能性需求
24 GA Gap Analysis
差距分析
25 ID
Interface Design
接口设计
26 IFPUG International Function Point
Users Group
国际功能点用户组织
27 IPM Integrated Project Management
集成项目管理
28 IR
Interface Requirement
接口需求
29 KPA Key Process Area
关键过程域
30 KR Key
Requirements
关键需求
31 LA Lead Assessor
主任评审员
32 MA
Measurement and Analysis
测量与分析
33 MAT
Metrics Advisory Team
度量咨询组
34 MCA Metrics Coordinator and Analyst
度量专员
35 ML
matreraty library
度量数据库
36 NFR Non-functional Requirement
非功能性需求
37 OC
Operational Concept
操作概念
38 OID Organizational Innovation and
Deployment
组织革新与部署
39 OPD Organizational Process
definition
组织过程定义
40 OPF Organizational Process focus
组织过程焦点
41 OPL
Organizational Process Assets
组织过程财富
42 OPP
Organaizational Process Perormance
组织过程性能
43 OSSP
Organization
’
s Set of
Standard Process
组织标准过程集合
44 OT Organizational Training
组织级培训
45 PA
Process Areas
过程域
46 PAT Process Action Team
过程行动小组
47 PB
Process Assets Library
过程财富库
48 PD Preliminary Design
概要设计
49 PDSP
Project Defined Standard Processes
项目定义标准过程
50 PI
Produce Integration
产品集成
51 PLC Product Life Cycle
产品生命周期
52 PMC
Project Monitoring and Control
项目监控
53 PP
Project Planning
项目策划
54 PPQA Process and Product Quality
Assurance
过程与产品质量保证
55 PPR Price Performance Ratio
性能价格比
56 QA
Software Quality Assurance
软件质量保证
57 QA
Quality Assurance
质量保证
58 QAP Software Quality Assurance Plan
质量保证计划
59 QPM
Quantitative Project Management
量化项目管理
60 RD
Requirements Development
需求开发
61 RM/ReqM
Requirements Management
需求管理
62 RSKM Risk Management
风险管理
63 RTM
Requirement Traceability Matrix
需求跟踪矩阵
64 SAM
Supplier Agreement Management.
供应协议管理
65 SC
Steering Committee
指导委员会
66 SCAMPI Standard CMMI Assessment
Method for Process Improvement
过程改进
CMMI
标
准评审方法
67 SCCB Software Configuration Control
Board
软件配置管理控制委员会
68 SCM Software Configuration
Management
软件配置管理
69 SDP Software Development Plan
软件开发计划
70 SEI
Software Engineering Institute (
美国
)
软件工程学院
71
SEPG Software Engineering Process Group
软件工程过程组
72 SPI
Software Process Improvement
软件过程改进
73 SPP
Software Project Planning
软件项目策划
74 SPTO
Software Project Tracking and Oversight
软件项目跟踪与监控
75 SR
System Requirements
系统需求
76 SRS Software Requirement
Specification
软件需求规格
77 SSM Software Subcontract Management
软件分包管理
78 SSR
Software System Requirement
软件系统需求
79 TS
Technical Solution
技术解决方案
80 UC Use Case
用例
81 UID User Interface Design
用户界面设计
82
V
AL Validation
确认
83 VER Verification
验证
84 WBS Work
Breakdown Structure
工作分解结构
85 WP Work Products
工作产品
86 Pre-
assessment
预评审
87
Baseline
基线
88
Quality Attribute
质量属性
89 Scenario
场景
2
以字母检索单词
A
ability to
perform
执行的能力
:
（参见
公共特性
/common
feature
）
acceptance criteria
接受标准
：为让用户、客户或其他授权组织接受，一个系统或组件所必须满足的
条件。
[IEEE-STD-610]
acceptance
testing
接受性测试
：用来
决定系统是否达到接受标准的正规测试，从而能够使客户决定是否接受系统。
[IEEE
-STD-610]
acting phase
行动阶段
：（参见
IDEAL
方法）
action item
行动项目<
/p>
：（
1
）列表中分配给个人或组进行处理
的一个单元。（
2
）已被接受的一项行动提议。
action proposal
行动提议
：文档化的修改过程或过程相关项的建议，用以防止缺陷预防活动中发
现的缺陷再发生。（参见
软件过程改进提议
/software
process improvement
proposal
）
activities performed
执行的活动
：（参见
公共特性
/common
features
）
activity
活动
：为达到某些目标而执行的一个步骤或一项功能，可能是脑力的也可能是体力的。包括管理和技术人<
/p>
员为执行项目或组织工作任务而进行的所有活动。（比照任务
/t
ask
）
Allocated
requirements
分配的需求
：参见系统分配至软件的需求
/system requirements
allocated to software
appraisal
评审
：是一个广泛意义上的词，可以是软件过程评估（
process ass
essment
），也可以是软件能力的评价
（
capability evaluation
）。
assessment
评估
：在
CMM
中，一般指内部的过程评估。
audit
审核
：对一个或一套工作产品的独立的检查，用以确定是否符合规格说明、标准、合同协议或
其他的准则。
[IEEE-STD-610]
B
baseline
基线
：经过正式审查并被一致认可的规格说明或产品，作为进一步开发基础
，只有通过正式变更控制程序
才能改变。
[IEEE-
STD-610]
baseline configuration
management
基线配置管理
：
建立经过正式评审和认同的基线，并将其作为进一步开发工作的基础。
一些软件工作产品，
如软件设计和代码应按计划建立基线，并使用严格的变更控
制过程进行管理。这些基线使得与客户的交互
在稳定及可控的状态下进行。（参见基线管
理
/baseline
management
）
benchmark
基准
：进行度量或比较的标准。
bidder
投标者
：个人、合作伙伴、公司或联
合组织提交了意向书，就成为了获取设计、开发、及
/
或制造一
个或
多个产品合同的候选者。
C
capability maturity
model
能力成熟度模型
：软件组
织通过定义、执行、度量、控制、改进软件过程而不断提高，能力成熟度模型就
是提高过
程不同阶段的描述。通过帮助确认当前过程能力，帮助确定那些对于软件质量和过程改进最迫切
< br>的问题，这个模型对于如何选择过程改进战略提供了指导。
causal analysis
诱
因分析
：分析缺陷来确定导致缺陷的根本原因。
causal analysis meeting
诱因分析会
：完成一项具体任务后所进行的会议，用来分析在完成任务期
间发现的缺陷。
commitment
承诺
：根据需要建立的、可见的且相
关各方应遵守的协定。
commitment to perform
执行的承诺：参见
公共特性
/common features
common
cause
（
of a
defect
）
缺陷的一般原因
：导致缺陷的来自系统或过程本身的原因。一般原因影响过程的每个结果和过程中的每个
人。（对照特殊原因
/special
cause
）
common
features
公共特性
：
是
CMM
关键过程域中内容的分类。
公共特性是表明一个关键过程域的制度化和实施是否有效、
可重复和持
续的属性。公共特性包括执行的承诺、执行的能力、执行的活动、度量和分析和执行的验证
·
commitment to perform
执行的承诺
为保证过程得以建立和持
久的，一个组织所必须采取的行动。执行的
承诺一般将包括建立组织政策和领导责任。<
/p>
·
ability to
perform
执行的能力
为有效
执行软件过程，
项目和组织所必须具备的一些前提条件。
执行的
能力
一般包括资源、组织结构和培训。
·
activities performed
进行的活动
对执行一个关键过程域所
必须的活动、
角色和规程的描述。
进行的活动一
般包括建立计划和规程、执行和跟踪工作以及在必要时采取更正措施。
·
measurement and analysis
度量与分析
对用以确定过程相关状态
所必须进行的基本度量做法的描述。这些
度量用来控制和改进过程。度量与分析一般包括
可以进行的度量的例子。
·
verifying implementation
验证实施
为确保活动与已建立过程保
持一致所采取的步骤。验证一般包括管理
者和软件质量保证组所进行的监察和审查。
configuration
配置
：
在配置管理中，
技术文档中描述的或软件产品中实现的软件或硬件的功能和物理特性。
[IEEE-
STD-610]
configuration
control
配置控制
：配置管理
的一个要素，包括评审、协调、批准或不批准以及正式建立配置标识后对配置项的更
改。
[IEEE-STD-610]
configuration
identification
配置标识
：
配置管理的一个要素，
包括为一个系统选择配置项并在技
术文档中记录它们的功能和物理特性。
[IEEE-STD-610]
configuration item
配置项
：为配置管理指定的软件、硬件或包括两者的一个集合，在配置管理过程中作
为一个独立实体。
configuration
management
配置管理
：是
使用技术及行政指导和监督的一个规范，用以确定和记录一个配置项的功能和物理特性，控
制对这些特性的修改，
记录并报告变更处理及执行的状态，
并
验证其与特定要求的符合性。
[IEEE-STD-610]
configuration management library
system
配置管理库系统
：访问
软件基线库内容的工具和规程。
configuration
unit
配置单元
：配置项或组件的
最底层实体，可以放入配置管理库系统，也可以从中提取。
consistency
一致性：统
一、标准化以及不与系统或组件中其它部分相矛盾的程度。
[IEEE-
STD-610]
contingency factor
或有因素
：对规模、费用或进度计划的调整（增加），以处理可
能发生的对这些项的低的估算，导致过低
估算的原因有不完整的规格说明、对应用领域的
估算缺乏经验等等。
contract terms and
conditions
合同条款与条件
：合同中描述的法律、财务及行政管理方面的内容。
critical computer resource
关键计算机资源
：可能带来项目风险的计算机资源，因为对这些
资源的需求会超出可用的数量。如运行机
的内存、开发机的磁盘空间。
< br>
critical path
关键路径
：必须按计划完成以使整个项目不脱离计划的一系列相互关联的任务。
customer
客户
：负责接受产品及有权支付开发组织的个人或组织。
D
defect
缺陷
< br>：系统或系统组件中导致系统或系统组件不能按要求功能执行缺陷。如果在系统运行时遇到缺陷将导
致系统失效。
defect
density
缺陷密度
：产品中缺
陷数除以产品的规模（以该产品标准度量尺度表示）
defect prevention
缺陷预防
：识别缺陷或潜在缺陷以及防止它们进入产品的各种活动。
< br>
defect root cause
缺陷根本诱因
：导致缺陷出现的根本原因（比如过程的不完善）。
defined level
已定义级
：参见成熟度等级
/maturity
level
。
defined
software process
定义软件过程
:
参见
项目定义软件过程
/project’s defined
software process
。
dependency item
相关项目
:
是指一个组或个人提供给
第二个组或个人的一个产品、活动、信息等，从而使第二个组能够执
行已计划的任务。<
/p>
developmental configuration
management
开发性配置管理
：应用技术和行政指令来指定和控制软件和相关技术文档，这些文档定义了开发过程中软
件工作产品的配置内容状态。开发性配置管理是由开发人员直接控制的。开发性配置管理下的各项不是基
线，但在开发过程的某些时间点上，它们可以基线化并放在基线配置管理下。
< br>
deviation
偏差<
/p>
：与适当的惯例、计划、标准、程序的明显的偏离。
Diagnosing phase
诊断阶段
：参见
IDEAL
方法
/IDEAL
approach
。
documented procedure
文档化的规程
：参见规程
/procedure
。
E
effective
process
有效的过程
：有效的
过程应具备以下特点：已执行的、成文的、必须遵循的、对使用者进行培训的、被度
量的
、能够改进的。
end user
最终用户
：是指系统在其运行环境中部署后，
< br>
为了预期的目的而使用系统的组或个人。
end user representatives
最终用户代表
：选定的最终用户的一部分
,<
/p>
它们代表所有最终用户。
engineering group
工程组
：代表一个工程规范的一组人（包括管理人员和技术人员）。工程规范的例子有
：系统工程、硬件
工程、系统测试、软件工程、软件配置管理以及软件质量保证。
established phase
建立阶段
：参见
IDEAL
方法。
evaluation
评价
：参见软件能力评价
/software capability
evaluation
。
event-driven review/activity
事件驱动审查
/
活动
< br>：因项目内发生了某事而进行的一次审查或其它活动（如，正式审查或生命周期某阶段
的完成）。（比照定期审查
/
活动
periodic
review/activity
）
F
findings
发现结果
：一次评估
(assessment)
、评价
(evaluation))
、审查
(audit)
或检查
(review
)
在调查范围内所发现的最重
要的事情、问题或机遇。
first-line software
manager
一线软件经理
：对由
软件工程师和其他相关人员组成的组织单元（如一个部门或项目组）的人员配置和活
动负
有直接管理活责任（包括技术指导、管理人员和薪资）的经理。
formal review
正式评
审
：把一个产品展示给最终用户、客户或其他相关方，以获取他们的认可和听取他们的意
见。正式
评审也可能是一次对项目过程中管理和技术活动的一次评审。
< br>
function
功能
：为达到一组目的或结果，由个人或工具所进行的一组相关的行动，这些行动是特定分配给他
们的或
是出于职责。
G
goals
目标
：一个关键过程域中所有关键实践的总结，用来确定是否一个组织或项目已经有
效地实施了这个关键
过程域。目标表明了每个关键过程域的范围、边界和意图。
group
组
：为一组任务或活动负责的部门、经理和个人的集合。组可以由许多组成方式，可以是一个兼
职的个人，
也可以是来自不同部门的几个兼职人员，或者一些全职的人员。
H
host
computer
宿主机（开发机）
：用来开发软件的计算机。（比照
目标机
/target
computer
）
I
IDEAL approach
IDEAL
方法
：
< br>SEI
描述软件过程改进周期的方法，基于以下几个方面：启动过程改进、分析软
件过程、建
立改进过程的机制、采取行动执行改进、总结并在组织范围内进一步提高。<
/p>
IDEAL
方法的
5
< br>个阶段为：
·
启动阶段：这是第一个阶段，在这个阶段组织支持和软件过程改进基础设施得以定义并开始建立。
·
诊断阶段：
第二个阶段，这个阶段通过评估建立了组织的软件过程成熟度基线，同时组织得到一套改进
的建议。
·
建立阶段：第三个阶段，软件过程改进基础设施得以建立，包括过程行动组的建立、软件过程改进战略
和策略计划的定义。
·
行动阶段：第四个阶段，改进得以具体实施。
·
总结提高阶段：最后一个阶段，对
软件过程改进教训进行分析，然后对软件过程改进过程做相应修改。
重新确定支持并为下
个改进周期设立新的目标。
infrastructure
基础
设施
：支撑一个组织或系统的框架结构，包括支持其运行的组织结构、政策、标准、培训
、设施及工
具。
initial
level
初始级
：（参见成熟度等
级
/maturity level
）
initiating phase
启动阶段
：（参见
IDEAL
方法
/IDEAL
approach
）
institutionalization
制度化
：建立支持方法、做法及规程的基础设施和文化，从而使这些方法、做法
和规程成为日常工作的方
式
,
即使那些
定义它们的人员离开也不受影响。
integrated
software management
集成软件管理
：基于组织标准软件过程和相关过程资产，统一并集成软案工程和管理活动，使其成为一个<
/p>
紧凑一致的定义软件过程。
integration
集成
：（参见软件集成
/software
integration
）
K
key practices
<
/p>
关键实践
：对关键过程域进行有效实施和制度化起关键作用的基础
设施和活动。
key process
area
关键过程域
：一组相关的活
动，当这些活动都被执行时，将实现一组被认为对建立过程能力重要的一组目
标。关键过
程域被定义在某一成熟度等级。它们是
SEI
定义的对于帮助确
定一个组织的软件过程能力的关
键组成要素，
它们还将帮助理解
达到更高成熟度等级所需的改进工作。
第二等级的关键过程域有需求管理、
软件项目计划、软件项目跟踪与监督、软件分包合同管理、软件质量保证和软件配置管理。第三等级的
关
键过程域包括组织过程中心、组织过程定义、培训方案、集成软件管理、软件产品工程
、组间协调和统计
互查。第四等级的关键过程域包括定量过程管理和软件质量管理。第五
等级的关键过程域包括缺陷预防、
技术变更管理和过程变更管理。
L
leveraging phase
总结提高阶段
：（参见
IDEAL
方法
/ IDEAL
approach
）
life cycle
生存周期
：（参见软件生存周期
/software life
cycle
）
M
maintenance
维护
：软件系统交付后修改系统或部件以改正缺陷、改善性能或其它属
性、或适应新的环境的过程。
[IEEE-STD-610]
managed and controlled
管理和控制
：有些软件工作产品不是基线的一部分，因此没有纳入配置管理
，但为使项目以规范的方式进
行必须对其进行控制，
“
管理和控制
”
就是确认和定义这些工作产品的过
程。它要求在一个给定时间（过去
和现在）的某个正在使用的工作产品的版本是可知的（
即版本控制），工作产品的修改以受控的方式进行
（即变更控制）。
managed level
已管理级
：（参见成熟度等级
/maturity
level
）
manager
经理
：为在经理责任范围内工作的人员提供技术和行政指导和控制的角色。经理的一些传统职责有在责任
范围内的计划、资源调配、组织、指导和控制工作。
maturity level
成熟
度等级
：妥善定义的为实现成熟的软件过程渐进的平台。
SEI
的能力成熟度模型的
5
个等级是：
·
初始级
软件过程是反应型的，有时甚
至是混乱的。很少有定义的过程，成功依赖于个人的努力。
·
可重复级
基本的项目管理过程得以建立，来跟踪费用、进度和功能性。有必要的过程规范，以重复
以前
的类似应用领域项目的成功。
·
已定义级
管理和技术的软件过程得以记录于文档、标准化并集成为组织的标准软件过程。所有的项
目使
-
-
-
-
-
-
-
-
-
上一篇：高考英语全国卷2016 I 完形填空翻译与解析
下一篇：一些常用的英文缩写