CMMI中英文术语对照表.doc

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 VAL 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
行动项目：（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
软件开发计划：描述软件项目活动的一