CMMI中英文术语对照表.docx
《CMMI中英文术语对照表.docx》由会员分享，可在线阅读，更多相关《CMMI中英文术语对照表.docx（21页珍藏版）》请在冰点文库上搜索。
CMMI中英文术语对照表
CMMI中英文术语对照表
A
abilitytoperform
执行的能力:
（参见公共特性/commonfeature）
acceptancecriteria
接受标准：
为让用户、客户或其他授权组织接受，一个系统或组件所必须满足的条件。
[IEEE-STD-610]
acceptancetesting
接受性测试：
用来决定系统是否达到接受标准的正规测试，从而能够使客户决定是否接受系统。
[IEEE-STD-610]
actingphase
行动阶段：
（参见IDEAL方法）
actionitem
行动项目：
（1）列表中分配给个人或组进行处理的一个单元。
（2）已被接受的一项行动提议。
actionproposal
行动提议：
文档化的修改过程或过程相关项的建议，用以防止缺陷预防活动中发现的缺陷再发生。
（参见软件过程改进提议/softwareprocessimprovementproposal）
activitiesperformed
执行的活动：
（参见公共特性/commonfeatures）
activity
活动：
为达到某些目标而执行的一个步骤或一项功能，可能是脑力的也可能是体力的。
包括管理和技术人员为执行项目或组织工作任务而进行的所有活动。
（比照任务/task）
Allocatedrequirements
分配的需求：
参见系统分配至软件的需求/systemrequirementsallocatedtosoftware
appraisal
评审：
是一个广泛意义上的词，可以是软件过程评估（processassessment），也可以是软件能力的评价（capabilityevaluation）。
assessment
评估：
在CMM中，一般指内部的过程评估。
audit
审核：
对一个或一套工作产品的独立的检查，用以确定是否符合规格说明、标准、合同协议或其他的准则。
[IEEE-STD-610]
B
baseline
基线：
经过正式审查并被一致认可的规格说明或产品，作为进一步开发基础，只有通过正式变更控制程序才能改变。
[IEEE-STD-610]
baselineconfigurationmanagement
基线配置管理：
建立经过正式评审和认同的基线，并将其作为进一步开发工作的基础。
一些软件工作产品，如软件设计和代码应按计划建立基线，并使用严格的变更控制过程进行管理。
这些基线使得与客户的交互在稳定及可控的状态下进行。
（参见基线管理/baselinemanagement）
benchmark
基准：
进行度量或比较的标准。
bidder
投标者：
个人、合作伙伴、公司或联合组织提交了意向书，就成为了获取设计、开发、及/或制造一个或多个产品合同的候选者。
C
capabilitymaturitymodel
能力成熟度模型：
软件组织通过定义、执行、度量、控制、改进软件过程而不断提高，能力成熟度模型就是提高过程不同阶段的描述。
通过帮助确认当前过程能力，帮助确定那些对于软件质量和过程改进最迫切的问题，这个模型对于如何选择过程改进战略提供了指导。
causalanalysis
诱因分析：
分析缺陷来确定导致缺陷的根本原因。
causalanalysismeeting
诱因分析会：
完成一项具体任务后所进行的会议，用来分析在完成任务期间发现的缺陷。
commitment
承诺：
根据需要建立的、可见的且相关各方应遵守的协定。
commitmenttoperform
执行的承诺：
参见公共特性/commonfeatures
commoncause（ofadefect）
缺陷的一般原因：
导致缺陷的来自系统或过程本身的原因。
一般原因影响过程的每个结果和过程中的每个人。
（对照特殊原因/specialcause）
commonfeatures
公共特性：
是CMM关键过程域中内容的分类。
公共特性是表明一个关键过程域的制度化和实施是否有效、可重复和持续的属性。
公共特性包括执行的承诺、执行的能力、执行的活动、度量和分析和执行的验证
·commitmenttoperform执行的承诺为保证过程得以建立和持久的，一个组织所必须采取的行动。
执行的承诺一般将包括建立组织政策和领导责任。
·abilitytoperform执行的能力为有效执行软件过程，项目和组织所必须具备的一些前提条件。
执行的能力一般包括资源、组织结构和培训。
·activitiesperformed进行的活动对执行一个关键过程域所必须的活动、角色和规程的描述。
进行的活动一般包括建立计划和规程、执行和跟踪工作以及在必要时采取更正措施。
·measurementandanalysis度量与分析对用以确定过程相关状态所必须进行的基本度量做法的描述。
这些度量用来控制和改进过程。
度量与分析一般包括可以进行的度量的例子。
·verifyingimplementation验证实施为确保活动与已建立过程保持一致所采取的步骤。
验证一般包括管理者和软件质量保证组所进行的监察和审查。
configuration
配置：
在配置管理中，技术文档中描述的或软件产品中实现的软件或硬件的功能和物理特性。
[IEEE-STD-610]
configurationcontrol
配置控制：
配置管理的一个要素，包括评审、协调、批准或不批准以及正式建立配置标识后对配置项的更改。
[IEEE-STD-610]
configurationidentification
配置标识：
配置管理的一个要素，包括为一个系统选择配置项并在技术文档中记录它们的功能和物理特性。
[IEEE-STD-610]
configurationitem
配置项：
为配置管理指定的软件、硬件或包括两者的一个集合，在配置管理过程中作为一个独立实体。
configurationmanagement
配置管理：
是使用技术及行政指导和监督的一个规范，用以确定和记录一个配置项的功能和物理特性，控制对这些特性的修改，记录并报告变更处理及执行的状态，并验证其与特定要求的符合性。
[IEEE-STD-610]
configurationmanagementlibrarysystem
配置管理库系统：
访问软件基线库内容的工具和规程。
configurationunit
配置单元：
配置项或组件的最底层实体，可以放入配置管理库系统，也可以从中提取。
consistency
一致性：
统一、标准化以及不与系统或组件中其它部分相矛盾的程度。
[IEEE-STD-610]
contingencyfactor
或有因素：
对规模、费用或进度计划的调整（增加），以处理可能发生的对这些项的低的估算，导致过低估算的原因有不完整的规格说明、对应用领域的估算缺乏经验等等。
contracttermsandconditions
合同条款与条件：
合同中描述的法律、财务及行政管理方面的内容。
criticalcomputerresource
关键计算机资源：
可能带来项目风险的计算机资源，因为对这些资源的需求会超出可用的数量。
如运行机的内存、开发机的磁盘空间。
criticalpath
关键路径：
必须按计划完成以使整个项目不脱离计划的一系列相互关联的任务。
customer
客户：
负责接受产品及有权支付开发组织的个人或组织。
D
defect
缺陷：
系统或系统组件中导致系统或系统组件不能按要求功能执行缺陷。
如果在系统运行时遇到缺陷将导致系统失效。
defectdensity
缺陷密度：
产品中缺陷数除以产品的规模（以该产品标准度量尺度表示）
defectprevention
缺陷预防：
识别缺陷或潜在缺陷以及防止它们进入产品的各种活动。
defectrootcause
缺陷根本诱因：
导致缺陷出现的根本原因（比如过程的不完善）。
definedlevel
已定义级：
参见成熟度等级/maturitylevel。
definedsoftwareprocess
定义软件过程:
参见项目定义软件过程/project’sdefinedsoftwareprocess。
dependencyitem
相关项目:
是指一个组或个人提供给第二个组或个人的一个产品、活动、信息等，从而使第二个组能够执行已计划的任务。
developmentalconfigurationmanagement
开发性配置管理：
应用技术和行政指令来指定和控制软件和相关技术文档，这些文档定义了开发过程中软件工作产品的配置内容状态。
开发性配置管理是由开发人员直接控制的。
开发性配置管理下的各项不是基线，但在开发过程的某些时间点上，它们可以基线化并放在基线配置管理下。
deviation
偏差：
与适当的惯例、计划、标准、程序的明显的偏离。
Diagnosingphase
诊断阶段：
参见IDEAL方法/IDEALapproach。
documentedprocedure
文档化的规程：
参见规程/procedure。
E
effectiveprocess
有效的过程：
有效的过程应具备以下特点：
已执行的、成文的、必须遵循的、对使用者进行培训的、被度量的、能够改进的。
enduser
最终用户：
是指系统在其运行环境中部署后，为了预期的目的而使用系统的组或个人。
enduserrepresentatives
最终用户代表：
选定的最终用户的一部分,它们代表所有最终用户。
engineeringgroup
工程组：
代表一个工程规范的一组人（包括管理人员和技术人员）。
工程规范的例子有：
系统工程、硬件工程、系统测试、软件工程、软件配置管理以及软件质量保证。
establishedphase
建立阶段：
参见IDEAL方法。
evaluation
评价：
参见软件能力评价/softwarecapabilityevaluation。
event-drivenreview/activity
事件驱动审查/活动：
因项目内发生了某事而进行的一次审查或其它活动（如，正式审查或生命周期某阶段的完成）。
（比照定期审查/活动periodicreview/activity）
F
findings
发现结果：
一次评估（assessment）、评价（evaluation））、审查（audit）或检查（review）在调查范围内所发现的最重要的事情、问题或机遇。
first-linesoftwaremanager
一线软件经理：
对由软件工程师和其他相关人员组成的组织单元（如一个部门或项目组）的人员配置和活动负有直接管理活责任（包括技术指导、管理人员和薪资）的经理。
formalreview
正式评审：
把一个产品展示给最终用户、客户或其他相关方，以获取他们的认可和听取他们的意见。
正式评审也可能是一次对项目过程中管理和技术活动的一次评审。
function
功能：
为达到一组目的或结果，由个人或工具所进行的一组相关的行动，这些行动是特定分配给他们的或是出于职责。
G
goals
目标：
一个关键过程域中所有关键实践的总结，用来确定是否一个组织或项目已经有效地实施了这个关键过程域。
目标表明了每个关键过程域的范围、边界和意图。
group
组：
为一组任务或活动负责的部门、经理和个人的集合。
组可以由许多组成方式，可以是一个兼职的个人，也可以是来自不同部门的几个兼职人员，或者一些全职的人员。
H
hostcomputer
宿主机（开发机）：
用来开发软件的计算机。
（比照目标机/targetcomputer）
I
IDEALapproach
IDEAL方法：
SEI描述软件过程改进周期的方法，基于以下几个方面：
启动过程改进、分析软件过程、建立改进过程的机制、采取行动执行改进、总结并在组织范围内进一步提高。
IDEAL方法的5个阶段为：
·启动阶段：
这是第一个阶段，在这个阶段组织支持和软件过程改进基础设施得以定义并开始建立。
·诊断阶段：
第二个阶段，这个阶段通过评估建立了组织的软件过程成熟度基线，同时组织得到一套改进的建议。
·建立阶段：
第三个阶段，软件过程改进基础设施得以建立，包括过程行动组的建立、软件过程改进战略和策略计划的定义。
·行动阶段：
第四个阶段，改进得以具体实施。
·总结提高阶段：
最后一个阶段，对软件过程改进教训进行分析，然后对软件过程改进过程做相应修改。
重新确定支持并为下个改进周期设立新的目标。
infrastructure
基础设施：
支撑一个组织或系统的框架结构，包括支持其运行的组织结构、政策、标准、培训、设施及工具。
initiallevel
初始级：
（参见成熟度等级/maturitylevel）
initiatingphase
启动阶段：
（参见IDEAL方法/IDEALapproach）
institutionalization
制度化：
建立支持方法、做法及规程的基础设施和文化，从而使这些方法、做法和规程成为日常工作的方式,即使那些定义它们的人员离开也不受影响。
integratedsoftwaremanagement
集成软件管理：
基于组织标准软件过程和相关过程资产，统一并集成软案工程和管理活动，使其成为一个紧凑一致的定义软件过程。
integration
集成：
（参见软件集成/softwareintegration）
K
keypractices
关键实践：
对关键过程域进行有效实施和制度化起关键作用的基础设施和活动。
keyprocessarea
关键过程域：
一组相关的活动，当这些活动都被执行时，将实现一组被认为对建立过程能力重要的一组目标。
关键过程域被定义在某一成熟度等级。
它们是SEI定义的对于帮助确定一个组织的软件过程能力的关键组成要素，它们还将帮助理解达到更高成熟度等级所需的改进工作。
第二等级的关键过程域有需求管理、软件项目计划、软件项目跟踪与监督、软件分包合同管理、软件质量保证和软件配置管理。
第三等级的关键过程域包括组织过程中心、组织过程定义、培训方案、集成软件管理、软件产品工程、组间协调和统计互查。
第四等级的关键过程域包括定量过程管理和软件质量管理。
第五等级的关键过程域包括缺陷预防、技术变更管理和过程变更管理。
L
leveragingphase
总结提高阶段：
（参见IDEAL方法/IDEALapproach）
lifecycle
生存周期：
（参见软件生存周期/softwarelifecycle）
M
maintenance
维护：
软件系统交付后修改系统或部件以改正缺陷、改善性能或其它属性、或适应新的环境的过程。
[IEEE-STD-610]
managedandcontrolled
管理和控制：
有些软件工作产品不是基线的一部分，因此没有纳入配置管理，但为使项目以规范的方式进行必须对其进行控制，“管理和控制”就是确认和定义这些工作产品的过程。
它要求在一个给定时间（过去和现在）的某个正在使用的工作产品的版本是可知的（即版本控制），工作产品的修改以受控的方式进行（即变更控制）。
managedlevel
已管理级：
（参见成熟度等级/maturitylevel）
manager
经理：
为在经理责任范围内工作的人员提供技术和行政指导和控制的角色。
经理的一些传统职责有在责任范围内的计划、资源调配、组织、指导和控制工作。
maturitylevel
成熟度等级：
妥善定义的为实现成熟的软件过程渐进的平台。
SEI的能力成熟度模型的5个等级是：
·初始级软件过程是反应型的，有时甚至是混乱的。
很少有定义的过程，成功依赖于个人的努力。
·可重复级基本的项目管理过程得以建立，来跟踪费用、进度和功能性。
有必要的过程规范，以重复以前的类似应用领域项目的成功。
·已定义级管理和技术的软件过程得以记录于文档、标准化并集成为组织的标准软件过程。
所有的项目使用批准的和裁剪的组织标准软件过程版本来开发和维护软件。
·已管理级软件过程和产品质量的详细度量数据得以收集。
软件过程和产品都得到量化的理解和控制。
·持续优化级在过程和试用的新观点和新技术的量化反馈基础上进行持续的过程改进。
maturityquestionnaire
成熟度问卷：
（参见软件过程成熟度问卷/softwareprocessmaturityquestionnaire）
measure
度量单位：
度量的单位（如源代码行数或设计文档的页数）。
measurement
度量：
某物的维数、容量、质量、数量等。
（如300行源代码，设计说明书有7页等。
）
method
方法：
建立取得期望结果或完成一项任务的准确且可重复方式的一套完整的规则和准则。
methodology
方法论：
是方法、规程和标准的集合，定义了开发一个产品所需工程方法的集成和综合。
milestone
里程碑：
按进度安排好的一个有人为之负责并用来度量进度的事件。
N
nontechnicalrequirement
非技术性需求：
影响和决定软件项目管理活动的协议、条件及/或合同条款。
O
operationalsoftware
操作软件：
一个系统交付用户并在指定环境中部署之后，在系统中使用和操作的软件。
optimizinglevel
持续优化级：
（参见成熟度模型/maturitylevel）
organization
组织：
公司中的一个单元，或把许多项目作为一个整体来管理的其它实体。
一个组织内的所有项目具有共同的高层经理和共同的政策。
organization’smeasurementprogram
组织度量方案：
处理组织度量需求相关元素的集合，包括定义组织范围的度量、收集组织度量数据的方法和做法、分析组织度量数据的方法和做法、组织的度量目标。
organization’ssoftwareprocessassets
组织软件过程资产：
是一个实体的收集，由组织维护，项目在开发、裁剪、维护和执行它们的软件过程时使用。
典型的软件过程资产包括：
·组织标准软件过程
·批准使用的软件生存周期描述
·裁剪组织标准软件过程的指导和准则
·组织软件过程数据库
·软件过程相关文档库
组织认为对执行过程定义和维护活动任何有用的实体都可以包含在过程资产中。
organization’ssoftwareprocessdatabase
组织软件过程数据库：
收集并提供软件过程数据和软件工作产品数据的数据库，尤其针对那些与组织标准软件过程有关的数据。
数据库包含或指针指向实际度量数据和为理解度量数据所需的相关信息，并对其合理性和可应用性进行评估。
过程和工作产品数据的例子有，软件规模、工作量、费用的估算，软件规模、工作量、费用的实际数据；生产率数据；同级互查覆盖率和效率；软件代码中发现缺陷的数量和严重程度。
organization’sstandardsoftwareprocess
组织标准软件过程：
指导在组织内的所有项目中建立公共软件过程的具有可操作性定义的基本过程。
它描述了每个软件项目合成到项目定义软件过程的基本过程元素。
它也描述了这些软件过程元素间的关系（如，顺序和接口）。
orientation
定向培训：
对那些监督和联系负责执行一项议题的人员的人所作的关于这项议题的概论介绍。
（对照培训/train）
P
Paretoanalysis
Pareto分析：
按缺陷的严重程度排序来分析缺陷。
Pareto分析是基于以19世纪经济学家VilfredoPareto命名的一个原理，即大多数的影响来自于相对很少的原因，80%的后果是由20%的可能原因造成的。
peerreview
同级互查：
为发现缺陷及进行改进而由作者的同事按照定义的规程对软件工作产品进行检查。
peerreviewleader
同级互查领导者：
接受过指定培训并有资格计划、组织和领导同级互查的个人。
periodicreview/activity
定期审查/活动：
按指定的有规律的时间间隔进行的一项审查或活动。
（参照事件驱动审查/活动/event-drivenreview/activity）
policy
政策：
指导性原则，一般由高层管理者建立，组织或项目将根据这个原则考虑和作出决定。
primecontractor
主承包商：
管理分承包商来设计、开发和/或制造一个或多个产品的个人、合作伙伴、公司或协会组织。
procedure
规程：
为完成一项既定任务而进行的一系列活动的书面描述。
[IEEE-STD-610]
process
过程：
为某一目的而进行的一系列步骤，例如，软件开发过程。
相对于规程（procedure），过程更强调做什么而不是怎么做。
[IEEE-STD-610]
processcapability
过程能力：
遵循某一过程而能够取得的预期结果的范围。
（参照过程绩效/processperformance）
processcapabilitybaseline
过程能力基线：
在特定环境中，执行某一具体过程通常得到的预期结果范围的书面描述。
过程能力基线一般在组织一级建立。
（参照过程绩效基线/processperformancebaseline）
processdatabase
过程数据库：
（参见组织软件过程数据库/organization’ssoftwareprocessdatabase）
processdescription
过程描述：
一个过程主要部件的操作性定义，是对一个过程需求、设计、行为或其它特征的完全、准确及可验证的文档描述。
通常还包括确定这些项是否满足的规程。
过程描述可能出现在任务、项目或组织级。
processdevelopment
过程开发：
定义和描述过程的活动。
通常包括计划、架构、设计、执行和验证。
processmeasurement
过程度量：
用来进行过程度量的一套定义、方法及活动，以及为了理解及弄清过程特征而进行的度量的结果。
processperformance
过程绩效：
对遵循某一过程而取得的实际结果的度量值。
（参照过程能力/processcapability）
processperformancebaseline
过程绩效基线：
对遵循一个过程而会取得的实际结果的书面描述，在比照实际过程绩效与期望过程绩效时用作基准。
过程绩效基线通常在项目级建立，初始过程绩效基线通常来自于过程能力基线。
（参照过程能力基线/processcapabilitybaseline）
processtailoring
过程裁剪：
通过详细描述、改编、完善过程要素细节或其他不完整过程描述，从而建立一个过程描述的活动。
通过过程裁剪，一个项目的具体商业需求通常得以确定。
profile
对照图：
计划或预期同实际情况的比照，通常会采用图形的形式，典型的例子就是针对时间的比照。
project
项目：
需要共同努力来于开发和/或维护某个特定产品的一项事业。
产品可能是硬件、软件及其它部件。
项目一般有其自己的资金、成本核算以及交付的日程。
project’sdefinedsoftwareprocess
项目定义软件过程：
是项目使用的具有可操作定义的软件过程。
升级会员 