CMMI中英文术语对照表

A
ability to perform
执行的能力: （参见 公共特性/common feature）
acceptance criteria
接受标准：为让用户、客户或其他授权组织接受，一个系统或组件所必须满足的条件。[IEEE-STD-610]
acceptance testing
接受性测试：用来决定系统是否达到接受标准的正规测试，从而能够使客户决定是否接受系统。[IEEE-STD-610]
acting phase
行动阶段：（参见 IDEAL 方法）
action item
行动项目：（1）列表中分配给个人或组进行处理的一个单元。（2）已被接受的一项行动提议。
action proposal
行动提议：文档化的修改过程或过程相关项的建议，用以防止缺陷预防活动中发现的缺陷再发生。（参见软件过程改进提议/software process improvement proposal）
activities performed
执行的活动：（参见 公共特性/common features）
activity
活动：为达到某些目标而执行的一个步骤或一项功能，可能是脑力的也可能是体力的。包括管理和技术人员为执行项目或组织工作任务而进行的所有活动。（比照任务/task）
Allocated requirements
分配的需求：参见系统分配至软件的需求/system requirements allocated to software
appraisal
评审：是一个广泛意义上的词，可以是软件过程评估（process assessment），也可以是软件能力的评价（capability evaluation）。
assessment
评估：在CMM中，一般指内部的过程评估。
audit
审核：对一个或一套工作产品的独立的检查，用以确定是否符合规格说明、标准、合同协议或其他的准则。[IEEE-STD-610]

 

B
baseline
基线：经过正式审查并被一致认可的规格说明或产品，作为进一步开发基础，只有通过正式变更控制程序才能改变。[IEEE-STD-610]
baseline configuration management
基线配置管理：建立经过正式评审和认同的基线，并将其作为进一步开发工作的基础。一些软件工作产品，如软件设计和代码应按计划建立基线，并使用严格的变更控制过程进行管理。这些基线使得与客户的交互在稳定及可控的状态下进行。（参见基线管理/baseline management）
benchmark
基准：进行度量或比较的标准。
bidder
投标者 ：个人、合作伙伴、公司或联合组织提交了意向书，就成为了获取设计、开发、及/或制造一个或多个产品合同的候选者。

 

C
capability maturity model
能力成熟度模型：软件组织通过定义、执行、度量、控制、改进软件过程而不断提高，能力成熟度模型就是提高过程不同阶段的描述。通过帮助确认当前过程能力，帮助确定那些对于软件质量和过程改进最迫切的问题，这个模型对于如何选择过程改进战略提供了指导。
causal analysis
诱因分析：分析缺陷来确定导致缺陷的根本原因。
causal analysis meeting
诱因分析会：完成一项具体任务后所进行的会议，用来分析在完成任务期间发现的缺陷。
commitment
承诺：根据需要建立的、可见的且相关各方应遵守的协定。
commitment to perform
执行的承诺：参见 公共特性/common features
common cause（of a defect）
缺陷的一般原因：导致缺陷的来自系统或过程本身的原因。一般原因影响过程的每个结果和过程中的每个人。（对照特殊原因/special cause）
common features
公共特性：是CMM关键过程域中内容的分类。公共特性是表明一个关键过程域的制度化和实施是否有效、可重复和持续的属性。公共特性包括执行的承诺、执行的能力、执行的活动、度量和分析和执行的验证
· commitment to perform 执行的承诺 为保证过程得以建立和持久的，一个组织所必须采取的行动。执行的承诺一般将包括建立组织政策和领导责任。
· 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
关键计算机资源：可能带来项目风险的计算机资源，因为对这些资源的需求会超出可用的数量。如运行机的内存、开发机的磁盘空间。
critical path
关键路径：必须按计划完成以使整个项目不脱离计划的一系列相互关联的任务。
customer
客户：负责接受产品及有权支付开发组织的个人或组织。

 

D
defect
缺陷：系统或系统组件中导致系统或系统组件不能按要求功能执行缺陷。如果在系统运行时遇到缺陷将导致系统失效。
defect density
缺陷密度：产品中缺陷数除以产品的规模（以该产品标准度量尺度表示）
defect prevention
缺陷预防：识别缺陷或潜在缺陷以及防止它们进入产品的各种活动。
defect root cause
缺陷根本诱因：导致缺陷出现的根本原因（比如过程的不完善）。
defined level
已定义级：参见成熟度等级/maturity level。
defined software process
定义软件过程: 参见 项目定义软件过程/project’s defined software process。
dependency item
相关项目: 是指一个组或个人提供给第二个组或个人的一个产品、活动、信息等，从而使第二个组能够执行已计划的任务。
developmental configuration management
开发性配置管理：应用技术和行政指令来指定和控制软件和相关技术文档，这些文档定义了开发过程中软件工作产品的配置内容状态。开发性配置管理是由开发人员直接控制的。开发性配置管理下的各项不是基线，但在开发过程的某些时间点上，它们可以基线化并放在基线配置管理下。
deviation
偏差：与适当的惯例、计划、标准、程序的明显的偏离。
Diagnosing phase
诊断阶段：参见 IDEAL方法/IDEAL approach。
documented procedure
文档化的规程：参见规程/procedure。

 

E
effective process
有效的过程：有效的过程应具备以下特点：已执行的、成文的、必须遵循的、对使用者进行培训的、被度量的、能够改进的。
end user
最终用户：是指系统在其运行环境中部署后， 为了预期的目的而使用系统的组或个人。
end user representatives
最终用户代表：选定的最终用户的一部分,它们代表所有最终用户。
engineering group
工程组：代表一个工程规范的一组人（包括管理人员和技术人员）。工程规范的例子有：系统工程、硬件工程、系统测试、软件工程、软件配置管理以及软件质量保证。
established phase
建立阶段：参见 IDEAL方法。
evaluation
评价：参见软件能力评价/software capability evaluation。
event-driven review/activity
事件驱动审查/活动：因项目内发生了某事而进行的一次审查或其它活动（如，正式审查或生命周期某阶段的完成）。（比照定期审查/活动 periodic review/activity）

 

F
findings
发现结果：一次评估(assessment)、评价(evaluation))、审查(audit)或检查(review)在调查范围内所发现的最重要的事情、问题或机遇。
first-line software manager
一线软件经理：对由软件工程师和其他相关人员组成的组织单元（如一个部门或项目组）的人员配置和活动负有直接管理活责任（包括技术指导、管理人员和薪资）的经理。
formal review
正式评审：把一个产品展示给最终用户、客户或其他相关方，以获取他们的认可和听取他们的意见。正式评审也可能是一次对项目过程中管理和技术活动的一次评审。
function
功能：为达到一组目的或结果，由个人或工具所进行的一组相关的行动，这些行动是特定分配给他们的或是出于职责。

 

G
goals
目标：一个关键过程域中所有关键实践的总结，用来确定是否一个组织或项目已经有效地实施了这个关键过程域。目标表明了每个关键过程域的范围、边界和意图。
group
组：为一组任务或活动负责的部门、经理和个人的集合。组可以由许多组成方式，可以是一个兼职的个人，也可以是来自不同部门的几个兼职人员，或者一些全职的人员。

 

H
host computer
宿主机（开发机）：用来开发软件的计算机。（比照 目标机/target computer）

I
IDEAL approach
IDEAL 方法：SEI描述软件过程改进周期的方法，基于以下几个方面：启动过程改进、分析软件过程、建立改进过程的机制、采取行动执行改进、总结并在组织范围内进一步提高。IDEAL 方法的5个阶段为：
· 启动阶段：这是第一个阶段，在这个阶段组织支持和软件过程改进基础设施得以定义并开始建立。
· 诊断阶段：第二个阶段，这个阶段通过评估建立了组织的软件过程成熟度基线，同时组织得到一套改进的建议。
· 建立阶段：第三个阶段，软件过程改进基础设施得以建立，包括过程行动组的建立、软件过程改进战略和策略计划的定义。
· 行动阶段：第四个阶段，改进得以具体实施。
· 总结提高阶段：最后一个阶段，对软件过程改进教训进行分析，然后对软件过程改进过程做相应修改。重新确定支持并为下个改进周期设立新的目标。
infrastructure
基础设施：支撑一个组织或系统的框架结构，包括支持其运行的组织结构、政策、标准、培训、设施及工具。
initial level
初始级：（参见成熟度等级/maturity level）
initiating phase
启动阶段：（参见 IDEAL 方法/IDEAL approach）
institutionalization
制度化：建立支持方法、做法及规程的基础设施和文化，从而使这些方法、做法和规程成为日常工作的方式,即使那些定义它们的人员离开也不受影响。
integrated software management
集成软件管理：基于组织标准软件过程和相关过程资产，统一并集成软案工程和管理活动，使其成为一个紧凑一致的定义软件过程。
integration
集成：（参见软件集成/software integration）

 

K
key practices
关键实践：对关键过程域进行有效实施和制度化起关键作用的基础设施和活动。
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个等级是：
· 初始级 软件过程是反应型的，有时甚至是混乱的。很少有定义的过程，成功依赖于个人的努力。
· 可重复级 基本的项目管理过程得以建立，来跟踪费用、进度和功能性。有必要的过程规范，以重复以前的类似应用领域项目的成功。
· 已定义级 管理和技术的软件过程得以记录于文档、标准化并集成为组织的标准软件过程。所有的项目使用批准的和裁剪的组织标准软件过程版本来开发和维护软件。
· 已管理级 软件过程和产品质量的详细度量数据得以收集。软件过程和产品都得到量化的理解和控制。
· 持续优化级 在过程和试用的新观点和新技术的量化反馈基础上进行持续的过程改进。
maturity questionnaire
成熟度问卷：（参见软件过程成熟度问卷/software process maturity questionnaire）
measure
度量单位：度量的单位（如源代码行数或设计文档的页数）。
measurement
度量：某物的维数、容量、质量、数量等。（如300行源代码，设计说明书有7页等。）
method
方法：建立取得期望结果或完成一项任务的准确且可重复方式的一套完整的规则和准则。
methodology
方法论：是方法、规程和标准的集合，定义了开发一个产品所需工程方法的集成和综合。
milestone
里程碑：按进度安排好的一个有人为之负责并用来度量进度的事件。

 

N
nontechnical requirement
非技术性需求：影响和决定软件项目管理活动的协议、条件及/或合同条款。

 

O
operational software
操作软件：一个系统交付用户并在指定环境中部署之后，在系统中使用和操作的软件。
optimizing level
持续优化级：（参见成熟度模型/maturity level）
organization
组织：公司中的一个单元，或把许多项目作为一个整体来管理的其它实体。一个组织内的所有项目具有共同的高层经理和共同的政策。
organization’s measurement program
组织度量方案：处理组织度量需求相关元素的集合，包括定义组织范围的度量、收集组织度量数据的方法和做法、分析组织度量数据的方法和做法、组织的度量目标。
organization’s software process assets
组织软件过程资产：是一个实体的收集，由组织维护，项目在开发、裁剪、维护和执行它们的软件过程时使用。典型的软件过程资产包括：
· 组织标准软件过程
· 批准使用的软件生存周期描述
· 裁剪组织标准软件过程的指导和准则
· 组织软件过程数据库
· 软件过程相关文档库
组织认为对执行过程定义和维护活动任何有用的实体都可以包含在过程资产中。
organization’s software process database
组织软件过程数据库：收集并提供软件过程数据和软件工作产品数据的数据库，尤其针对那些与组织标准软件过程有关的数据。数据库包含或指针指向实际度量数据和为理解度量数据所需的相关信息，并对其合理性和可应用性进行评估。过程和工作产品数据的例子有，软件规模、工作量、费用的估算，软件规模、工作量、费用的实际数据；生产率数据；同级互查覆盖率和效率；软件代码中发现缺陷的数量和严重程度。
organization’s standard software process
组织标准软件过程：指导在组织内的所有项目中建立公共软件过程的具有可操作性定义的基本过程。它描述了每个软件项目合成到项目定义软件过程的基本过程元素。它也描述了这些软件过程元素间的关系（如，顺序和接口）。
orientation
定向培训：对那些监督和联系负责执行一项议题的人员的人所作的关于这项议题的概论介绍。（对照培训/train）

 

P
Pareto analysis
Pareto 分析：按缺陷的严重程度排序来分析缺陷。Pareto 分析是基于以19世纪经济学家Vilfredo Pareto命名的一个原理，即大多数的影响来自于相对很少的原因，80%的后果是由20%的可能原因造成的。
peer review
同级互查：为发现缺陷及进行改进而由作者的同事按照定义的规程对软件工作产品进行检查。
peer review leader
同级互查领导者：接受过指定培训并有资格计划、组织和领导同级互查的个人。
periodic review/activity
定期审查/活动：按指定的有规律的时间间隔进行的一项审查或活动。（参照 事件驱动审查/活动 / event-driven review/activity）
policy
政策：指导性原则，一般由高层管理者建立，组织或项目将根据这个原则考虑和作出决定。
prime contractor
主承包商：管理分承包商来设计、开发和/或制造一个或多个产品的个人、合作伙伴、公司或协会组织。
procedure
规程：为完成一项既定任务而进行的一系列活动的书面描述。[IEEE-STD-610]
process
过程：为某一目的而进行的一系列步骤，例如，软件开发过程。相对于规程(procedure)，过程更强调做什么而不是怎么做。[IEEE-STD-610]
process capability
过程能力：遵循某一过程而能够取得的预期结果的范围。（参照过程绩效/process performance）
process capability baseline
过程能力基线：在特定环境中，执行某一具体过程通常得到的预期结果范围的书面描述。过程能力基线一般在组织一级建立。（参照过程绩效基线/process performance baseline）
process database
过程数据库：（参见组织软件过程数据库/ organization’s software process database）
process description
过程描述：一个过程主要部件的操作性定义，是对一个过程需求、设计、行为或其它特征的完全、准确及可验证的文档描述。通常还包括确定这些项是否满足的规程。过程描述可能出现在任务、项目或组织级。
process development
过程开发：定义和描述过程的活动。通常包括计划、架构、设计、执行和验证。
process measurement
过程度量：用来进行过程度量的一套定义、方法及活动，以及为了理解及弄清过程特征而进行的度量的结果。
process performance
过程绩效：对遵循某一过程而取得的实际结果的度量值。（参照过程能力/process capability）
process performance baseline
过程绩效基线：对遵循一个过程而会取得的实际结果的书面描述，在比照实际过程绩效与期望过程绩效时用作基准。过程绩效基线通常在项目级建立，初始过程绩效基线通常来自于过程能力基线。（参照过程能力基线/process capability baseline）
process tailoring
过程裁剪：通过详细描述、改编、完善过程要素细节或其他不完整过程描述，从而建立一个过程描述的活动。通过过程裁剪，一个项目的具体商业需求通常得以确定。
profile
对照图：计划或预期同实际情况的比照，通常会采用图形的形式，典型的例子就是针对时间的比照。
project
项目：需要共同努力来于开发和/或维护某个特定产品的一项事业。产品可能是硬件、软件及其它部件。项目一般有其自己的资金、成本核算以及交付的日程。
project’s defined software process
项目定义软件过程：是项目使用的具有可操作定义的软件过程。项目定义软件过程容易理解并充分体现项目特征，通过软件标准、规程、工具和方法来描述。项目定义软件过程是通过裁剪组织标准软件过程得到的，以使其符合项目的具体特征。（参见组织标准软件过程/organization’s standard software process，有效过程/effective process，妥善定过程/well-defined process）
project manager
项目经理：对整个项目负有完全责任的角色，是指导、控制、管理、调节建造软件或软硬件系统的个人。项目经理是最终对客户负责的人。
project software manager
项目软件经理：对项目所有软件活动负全责的角色，项目软件经理控制项目的所有软件资源。项目经理将与项目软件经理确定软件承诺。

 

 

Q
quality
质量：（1）一个系统、部件或过程满足指定的需求的程度。（2）一个系统、部件或过程满足客户或用户需要或期望的程度。[IEEE-STD-610]
quality assurance
质量保证：（参见软件质量保证/software quality assurance）
quantitative control
量化控制：分析一个软件过程、识别造成软件过程绩效偏差的特殊诱因、使软件过程绩效回到定义范围的基于量化或统计的技术。

 

R
repeatable level
可重复级：（参见 成熟度模型/maturity level）
required training
要求的培训：由组织规定的为履行某角色所要求的培训。
risk
风险：可能造成损失的事物。
risk management
风险管理：是一种问题分析的方法，通过利用风险概率来权衡风险以得到对所有可能风险的准确理解。风险管理包括风险识别、分析、确定优先级和控制。
risk management plan
风险管理计划：描述项目中要执行的风险管理活动的各种计划的总称。
role
角色：已定义的责任的一个集合单位，可以由一个或多个人承担。

 

S   A-D    E-L  M-R    S-Z
senior management
高层管理者: 组织中足够高层次的管理角色，主要关注组织的长期活力，而不是短期的项目或合同方面所涉及的问题、压力等。一般来说，工程的高层管理者将对多个项目负责。
software architecture
软件架构（软件体系结构）：软件或模块的组织结构。[IEEE-STD-610]
software baseline audit
软件基线审核：对软件基线库中的结构、内容和设施进行检查，以验证是否这些基线与描述基线的文档一致。
software baseline library
软件基线库：存储的配置项和相关记录的内容。
software build
构建软件：软件系统或部件的一个可运行版本，包括了最终提供的软件系统或部件能力的一个特定子集。[IEEE-STD-610]
software capability evaluation
软件能力评价：由接受过培训的专业团队进行的评审，来确定那些合格的软件承包商，或对正在进行的软件工作过程进行监控。
software configuration control board
软件配置控制委员会：负责评价和批准/否决对配置项修改提议，确保批准的修改得以执行的组。
software development plan
软件开发计划：描述软件项目活动的一组计划，它支配着软件工程组项目活动的管理。这里的定义不受限于任何其他特定计划标准所描述的范围，如DOD-STD-2167A 和 IEEE-STD-1058，它们可能使用相同叫法。
software engineering group
软件工程组：负责某一项目软件开发和维护活动（即需求分析、设计、编码和测试）的一组人（包括经理和技术人员）。执行软件相关活动的组（如软件质量保证组、软件配置管理组和软件工程过程组）不包括在内。
software engineering process group
软件工程过程组：促进组织使用的软件过程定义、维护和改进工作的一组专家。在关键实践中，这个组通常被描述为“负责组织软件过程活动的组”。
software engineering staff
软件工程人员：指软件技术人员（如分析员、程序员和工程师），包括执行软件开发和维护的软件任务的领导者，但他们不是经理。
software integration
软件集成：把选取的软件部件集成的过程，以提供最终交付的软件系统能力的全部或特定子集。
software life cycle
软件生命周期：一个软件产品从开始构思到不再可用的持续时间。典型的软件生命周期包括概念阶段、需求阶段、设计阶段、执行阶段、测试阶段、安装、校验、操作和维护阶段，有时还会有退出阶段。[IEEE-STD-610]
software manager
软件经理：对软件开发和/或维护有直接责任的项目中的或组织层的任何经理。
software plans
软件计划：正式或非正式的一组计划，用来描述软件开发和/或维护活动如何开展。计划的一些例子有：软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划、过程改进计划。
software process
软件过程：人们用来开发和维护软件及相关产品（如项目计划、设计文档、代码、测试用例、用户手册）的活动、方法、做法和变革的集合。
software process assessment
软件过程评估：由接受过培训的一组软件专业人员所进行的评估，用以确定一个组织的当前软件过程状态，确定组织面临的软件过程相关问题的优先级，并获得对于进行软件过程改进的组织一级的支持。
software process assets
软件过程资产：（参见组织软件过程资产/organization’s software process assets）
software process capability
软件过程能力：（参见过程能力/process capability）
software process description
软件过程描述：项目定义软件过程（project’s defined software process ）或组织标准软件过程（organization’s standard software process）中一个主要软件过程部件的可操作的描述。它以完全的、准确的、可验证的方式记录了一个软件过程的需求、设计、行为或其它特性。（参见过程描述/process description）
software process element
软件过程元素：一个软件过程描述的构成元素。每一个过程元素涵盖了一套妥善定义的、有边界的、紧密联系的任务（如，软件估算元素、软件设计元素、编码元素、同级互查元素）。过程元素的描述可以是待填充内容的模板、需完善的片段、进一步细化的抽象元素或者是可以直接或修改后使用的完整描述。
software process improvement plan
软件过程改进计划：根据软件过程评审的建议制定的一个计划，计划中确定了将采取的改进软件过程的具体做法，还描述了执行这些做法的计划。有时也叫做行动计划。
software process improvement proposal
软件过程改进提议：改变过程或过程相关条目的书面建议，以改进软件过程能力和过程绩效。（参见行动提议/action proposal）
software process maturity
软件过程成熟度：一特定过程明确定义、管理、度量、控制和有效的程度。成熟度意味着能力成长的潜力，表明组织软件过程的丰富性和在组织内各项目中应用的一致性。
software process maturity questionnaire
软件过程成熟度问卷：关于软件过程的一套问题，它们是CMM每个关键过程域中关键实践的例子。成熟度问卷被用作评估一个组织或项目可靠地执行一个软件过程的能力的出发点。
software process performance
软件过程绩效：（参见过程绩效/process performance）
software process-related documentation
软件过程相关文档：是一些文档和文档片段的例子，当未来项目裁剪组织标准软件过程时，这些例子会有用。软件过程相关文档的一些例子有，项目定义软件过程、标准、规程、软件开发计划、度量计划以及过程培训材料。
software product
软件产品：一整套或一套中的个别项的交付给客户或最终用户的计算机程序、规程以及相关文档和数据。[IEEE-STD-610] (参见 软件工作产品/software work product )
software project
软件项目：是需要共同努力的一项事业。致力于分析、说明、设计、开发、测试和/或维护一个系统的软件部件以及相关文档。一个软件项目可以是建造一个硬件/软件系统的一部分。
software quality assurance
软件质量保证：（1）为一个软件工作产品与已建立技术需求一致提供足够的信心，而对所有必要活动所建立的一个系统的、有计划的模式。（2）为软件工作产品的开发和/或维护过程的评估所设计的一整套活动。
software quality goal
软件质量目标：为一个软件工作产品定义的量化的质量目标。
software quality management
软件质量管理：为软件产品定义质量目标、建立实现这些目标的计划、监控并调整软件计划、软件工作产品、活动以及质量目标，以满足客户和最终用户的需要与愿望。
software-related group
软件相关组：代表一个软件工程规范的一组人（包括管理者和技术人员），他们支持但不直接对进行软件开发和维护负责。软件工程规范的例子有软件质量保证、软件配置管理。
software requirement
软件需求：为解决软件用户一个问题或达到一个目标，软件必须满足的条件或达到的能力。 [IEEE-STD-610]
software work product
软件工作产品：定义、维护或应用一个软件过程的工作结果。通常包括过程描述、计划、步骤、计算机程序以及相关文档，这些物件有些是要提交给客户或最终用户的，有些不需要。（参照软件产品/software product）
special cause(of a defect)
（缺陷的）特殊诱因：由于暂时的特殊环境而导致缺陷的诱因，这些诱因并不是过程所固有的。特殊诱因导致过程绩效随机的变化（噪音）。（参照一般诱因/common cause）
staff
职员：一些个人，包括任务领导者。这些任务领导者对完成一项分配的功能负责（如，软件开发或软件配置管理），但他们不是经理。
stage
阶段：可管理规模的一部分软件工作，代表了项目所执行相关任务的一个有意义和可度量的集合。一个阶段通常被看作软件生存周期的细分，结束时并在下一阶段正式开始前通常举行一次正式评审。
standard
标准：采用并必须执行的强行标准，以为软件开发规定一个规范统一的方法。
standard software process
标准软件过程：（参照组织标准软件过程/ organization’s standard software process）
statement of work
工作综述：由客户提供的为完成项目所需的所有工作的描述。
subcontract manager
转包（分包）合同经理：是主承包商组织中的一个经理，他直接管理一个或多个转包（分包）合同的执行和控制。
subcontractor
分包商：与一个组织（如，主承包商）签订合同的个人、合作伙伴、公司或协会组织，来设计、开发和/或制造一种或多种产品。
system
系统：为完成一个特定的功能或功能集合而组织在一起的一些部件。[IEEE-STD-610]
system engineering group
系统工程组：系统工程组是这样一组人（包括管理者和技术人员），他们负责确定系统需求；将系统需求分配给软件、硬件或其他部分；指定硬件、软件和其他部分的接口；监控这些部分的设计与开发已确保与需求规格一致。
system requirement
系统需求：一个系统或系统部件所必须达到的条件或拥有的能力，以满足用户为解决问题所需的条件和能力。
system requirements allocated to software
系统分配至软件的需求：将由系统的软件部件实现的系统需求的子集。分配的需求是软件开发计划的主要输入。软件需求分析详细阐述和精炼分配的需求并产生软件需求文档。

 

T
tailor
裁剪：修改过程、标准或规程以更好地符合过程或产品的需求。
target computer
目标机（运行机）：运行交付的软件的计算机。（比照宿主机/host computer）
task
任务：（1）被看作一个基本工作单元的一系列指令。（2）是指软件过程中一个妥善定义的单元，是管理者了解项目状态的一个可见的检查点。任务有进入标准（前提条件）和结束标准（推出条件）。（比照活动/activity）
task kick-off meeting
任务动员会：在一项任务或一个工程开始时召开的会议，为了让所有参与这项任务的人做好准备以更有效地完成任务。
task leader
任务领导者：完成某一特定任务的技术小组的领导者，他对技术负责并对小组成员提供技术指导。
team
小组：为组织或项目执行一个妥善定义的功能的一组人，他们通常来自不同但相关的组。小组的成员可能是还有其它主要工作的兼职人员。
testability
可测试性：（1）一个系统或组件便于建立测试标准和便于进行测试以确定是否满足这些标准的程度。（2）一份需求描述得允许建立测试标准和允许测试以确定是否达到这些标准的程度。[IEEE-STD-610]
technical requirements
技术需求：描述软件必须做什么和操作限制的需求。如功能、性能、接口以及质量需求。
technology
技术：对科学和/或工程学的应用，以实现某些特定结果。
total quality management
全面质量管理：应用量化的方法和人力资源来改进提供给组织的材料与服务、组织内的所有的过程以及满足客户当前和未来需要的程度。
traceability
可跟踪性：能够在开发过程中的两个或多个产品间建立关系的程度，尤其针对那些有前后继承关系和主从关系的产品。[IEEE-STD-610]
train
培训：通过专门的指导和练习而达到熟练的程度。
training group
培训组：对一个组织的培训安排和协调负责的一组人（包括经理和普通员工）。这组人通常准备和进行大多数的培训课程，并协调其他培训设施的使用。
training program
培训方案:用来满足组织培训需求的一套相关元素。包括组织的培训计划、培训材料、培训的开发、培训活动、培训设施、培训的评价以及培训记录的维护。
training vaiver
免培训：书面批准某人免除一特定角色所要求的培训。之所以可以免培训，是因为已客观地确定他已具备担负角色所需的技能。

 

U
unit
单元：（1）在设计一个计算机软件组件时，指定的一个分开独立测试的元素。（2）计算机程序中，逻辑上可分开的部分。（3）不再分拆成其它组件的一个软件组件。[IEEE-STD-610]
user
用户：（参见最终用户/end user）

 

V
validation
检验：在开发过程中或结束时评价软件,确定是否符合指定的需求。[IEEE-STD-610]
verification
验证：评价软件，来确定特定开发阶段的产品是否满足阶段开始时要求的条件。[IEEE-STD-610]
verifying implementation
检验实施：参见公共特性/common features

 

W
waiver
免培训：参见 免培训/training waiver。
well-defined process
妥善定义的过程：一个妥善定义的过程应具备以下特性：准备标准、输入、进行工作所依据的标准和程序、验证机制（如同级互查）、输出、结束标准。(参见 有效的过程/effective process)