CMM术语表详细说明

CMM术语表
目录
1. 过程成熟度   4
2. CMM   4
3. 关键过程域   4
4. 软件生命周期   4
5. 需求管理   4
6. 软件项目策划   4
7. 软件项目跟踪与监督   4
8. 软件质量保证   4
9. 软件配置管理   4
10. 组织过程焦点   4
11. 组织过程定义   4
12. 培训大纲   4
13. 集成软件管理   4
14. 软件产品工程   4
15. 组间协调   4
16. 同行评审   4
17. 软件过程   4
18. 软件过程能力   4
19. 软件过程性能   4
20. 软件过程成熟度   4
21. 软件能力成熟度等级   4
22. 关键实践   4
23. 执行约定   4
24. 执行能力   4
25. 执行的活动   4
26. 测量和分析   4
27. 验证实施   4
28. 方针   4
29. 规程   4
30. 模板   4
31. 指南   4
32. 表单   4
33. 方法   4
34. 目标   4
35. 活动   4
36. 验证   4
37. 高级经理   4
38. 项目经理   4
39. 软件产品   4
40. 其他相关组   4
41. 一线软件经理   4
42. 软件作业领导   4
43. 基线   4
44. 变更管理   4
45. 配置项   4
46. 配置标识   4
47. 开发库   4
48. 受控库   4
49. 发布库   4
50. 对象模型   4
51. 工件   4
52. 设计   4
53. 开发案例   4
54. 业务需求   4
55. 软件需求   4
56. 系统需求   4
57. 分析类   4
58. 设计类   4
59. 构件   4
60. 规模   4
61. 工作量   4
62. 代码行   4
63. 验收准则   4
64. 风险   4
65. 约定   4
66. 关键计算机资源   4
67. 软件项目   4
68. 里程碑   4
69. 审批   4
70. 评审   4
71. 审定   4
72. 审计   4
73. 用户需要   4
74. 系统特性   4
75. 用例   4
76. 补充需求   4
77. 请求   4
78. 研究开发中心   4
79. 方案实施部   4
80. 产品部   4
81. 分析设计部   4
82. 开发部   4
83. 测试组   4
84. 软件质量保证组   4
85. 软件配置管理组   4
86. 配置控制委员会   4
87. 信息中心   4
88. 系统工程组   4
89. 软件工程组   4
90. 管理指导委员会   4
91. 软件工程过程组   4
92. 评审员   4
93. 读者   4
94. 记录员   4
95. 协调者   4
96. 作者   4

CMM类术语
1.   过程成熟度
Process Maturity
是一个特定过程被明确地定义、管理、测量、控制、并且有效的程度。成熟度意味着能力上的增长潜力，并且表明一个组织软件过程的丰富性和在遍及组织的项目中运用它时的一致性。在成熟组织中，通常通过文档和培训使全组织有关人员对软件过程都能很好的了解，并且使该过程得到其用户不断的监控与改造。一个成熟软件组织的能力是已知的。软件过程成熟度意味着，由于运用组织的软件过程使过程纪律性一致增强，从而其软件过程所导致的生产率和质量能随时间的推移得到改进。
2.   CMM
Capability Maturity Model
CMM
即软件能力成熟度模型。一个软件过程可以定义为人们用以开发和维护软件及其相关产品（例如，项目计划、设计文档、代码、测试用例、用户手册等）等的一组活动、方法、实践和变化。随着一个组织的成熟，其软件过程得到更好的定义，并在整个组织内得到更一致的实施。
3.   关键过程域
Key Process Area
KPA
每个成熟度等级由若干个关键过程域组成。每个关键过程域标示出一串相关的活动，当这些活动全部完成时，能达到一组对增强过程能力至关重要的目标，此组目标对建立该过程成熟度等级至关重要。每个关键过程域是分别定义在各个成熟度等级上并与之相连在一起的。
4.   软件生命周期
Software Life Cycle
从提出开发软件到软件最终停止使用的整个过程叫软件生命周期，一般包括提出需求、需求分析、设计、编码、测试、维护等阶段。
5.   需求管理
Requirement Management
RM
CMM2的一个KPA，其目的是管理和控制需求，维护软件计划、产品和活动与需求的一致性，并保证需求在软件项目中得到实现。
6.   软件项目策划
Software Project Planning
SPP
CMM2的一个KPA，其目的是为完成和管理软件项目制定合理的计划。

7. 软件项目跟踪与监督
Software Project Tracking and Oversight
SPTO
CMM2的一个KPA，其目的是对项目的实际进展状况保持一定的可视性，一旦软件项目的性能明显偏离软件计划时，管理者能采取有效的行动。

8. 软件质量保证
Software Quality Assurance
SQA
CMM2的一个KPA，其目的是为管理者提供软件产品生产过程及软件产品的可视性。

9. 软件配置管理
Software Configuration Management
SCM
CMM2的一个KPA，其目的是建立和维护在整个软件生存周期内软件产品的完整性。

10. 组织过程焦点
Organization Process Focus
OPF
CMM3的一个KPA，其目的是建立组织对软件过程活动的责任，为组织的整体软件过程能力的不断提高提供组织上的保证。

11. 组织过程定义
Organization Process Definition
OPD
CMM3的一个KPA，其目的是由负责组织软件过程活动的组在组织层上定义软件过程，包括制定和维护组织的标准软件过程以及相关的过程财富。

12. 培训大纲
Training Program
TP
CMM3的一个KPA，其目的是采用各种培训方式提高个人的技能和知识，以便有效完成所承担的任务。

13. 集成软件管理
Integrated Software Management
ISM
CMM3的一个KPA，其目的是协调软件项目的工程活动和管理活动。

14. 软件产品工程
Software Product Engineering
SPE
CMM3的一个KPA，其目的是协调一致地执行一个妥善定义的工程过程、有效地生产正确的、一致的软件产品。

15. 组间协调
Inter-group Coordination
IC
CMM3的一个KPA，其目的是协调软件过程中各组的工作，以使项目在各方面更好地满足客户的需要。
16. 同行评审
Peer Review
PR
CMM3的一个KPA，其目的是为了及早和高效地从软件工作产品中识别并消除缺陷。

17.   软件过程
Software Process
用于开发和维护软件产品及其相关工件的一系列活动，包括软件工程活动和软件管理活动。
18.   软件过程能力
Software Process Capability
描述通过遵循软件过程能够实现预期效果的程度。一个组织的软件过程能力提供一种预测该组织承担下一个软件项目时最可能的预期结果的方法。
描述（开发组织或项目组）遵循其软件过程能够实现预期结果的程度，它既可对整个软件开发组织而言，也可对一个软件项目而言。
19.   软件过程性能
Software Process Performance
表示遵循软件过程所得到的实际结果。所以，软件过程性能关注已得到的结果，而软件过程能力则关注预期的结果。由于一个特定的项目的属性和执行该项目的环境所限，该项目的实际性能可能并不充分反映组织的整个过程能力，即项目的能力受限于它的环境。例如，项目在应用领域或所采用的技术上的根本改变可能造成其职员在处于学习状态，这使得他们的项目能力和性能远达不到该组织的整个过程能力。
20.   软件过程成熟度
Software Process Maturity
是一个特定过程被明确地定义、管理、测量、控制、并且有效的程度。成熟度意味着能力上的增长潜力，并且表明一个组织软件过程的丰富性和在遍及组织的项目中运用它时的一致性。在成熟组织中，通常通过文档和培训使全组织有关人员对软件过程都能很好的了解，并且使该过程得到其用户不断的监控与改造。一个成熟软件组织的能力是已知的。软件过程成熟度意味着，由于运用组织的软件过程使过程纪律性一致增强，从而其软件过程所导致的生产率和质量能随时间的推移得到改进。
一个特定软件过程被明确和有效地定义，管理测量和控制的程度。
21.   软件能力成熟度等级
Software Capability Maturity Level
成熟度等级是妥善定义的在向成熟软件组织前进的过程中的平台，每一个成熟度等级为过程改进提供一个台基。每一等级包含一组过程目标，当目标满足时，就能使软件过程的一个重要成分稳定。每达到成熟度框架的一个等级，就建立起软件过程的一个不同的成分，导致组织过程能力的增长。
22.   关键实践
Key Practice
KP
每个关键过程域用一些能对实现其目标做贡献的关键实践加以描述，当实施这些关键实践时，能帮助实现该关键过程域的目标。关键实践描述对关键过程域的有效实施和规范化贡献最大的基础设施和活动。
23.   执行约定
Commitment to Perform
执行约定描述组织保证过程得以建立和继续起作用所必须采取的行动，也是企业为了建立和实施相应KPA 所必须采取的行动。一般包含指定组织的方针和规定高级管理者的支持，这些行动主要牵涉到企业范围的政策和高层管理的责任。
24.   执行能力
Ability to Perform
执行能力描述为了使某软件过程得以始终如一地执行的必须在项目或企业中存在的先决条件，是企业实施KPA 的前提条件。企业必须采取措施，在满足了这些条件后，才有可能执行KPA 的实践活动。执行能力关注于：资源、组织结构、以及各种有关的培训等。这些都是为了执行这个关键过程域的活动而对特定的人以及作为整体的组织的能力开发起非常重要作用的事务。
25.   执行的活动
Activities Performed
执行的活动描述了执行一个KPA 所必需的角色和规程。在五个公共属性中，执行的活动是唯一与项目执行相关的属性，其余四个属性则涉及企业CMM 能力基础设施的建立。实施活动一般包括：制定计划和规程、执行任务、任务执行的跟踪，并在必要时采取纠正措施。
26.   测量和分析
Measurement and Analysis
测量和分析关注于对这个关键过程域的活动需要作的测量和测量结果的分析。典型的测量和分析的要求是确定执行活动的状态和执行活动的有效性。
27.   验证实施
Verifying Implementation
验证实施是验证执行活动是否与建立的过程一致，以确保所实施的过程是按照原定的计划进行并达到其目标。着眼于保证过程的实现要通过独立的个人和高级管理人员验证。涉及到管理者和质量保证部门的评审和审计活动，包括：过程执行的确保，产品要求的确保，高层管理人员进行的审核和项目经理进行的审核。
28.   方针
Policy
阐述软件开发与管理的目标及约定。
29.   规程
Procedure
用于详细说明过程中较为复杂的活动的规范化文档，要求必须遵照执行。主要内容有目的、范围、进入准则、输入、角色及职责、步骤、退出准则、输出等。
30.   模板
Template
各项活动所产生的工件必须遵循的格式及准则。定义好的模板只能使用，不能修改。
31.   指南
Guideline
指南介绍有助于角色执行活动的技巧和实用的建议。
32.   表单
Form
角色执行活动中要用到的格式固定的表格。
33.   方法
Method
完成工作要用到的有效的技巧的文档化描述。
34.   目标
Goal
概括一个关键过程域的关键实践，可用来确定一个组织或一个项目是否已有效实现该关键过程域。目标表现每个关键过程域的范围、边界和意图。
35.   活动
Activity
要求角色执行的工作单元，活动的三要素是角色、工具、规程。
36.   验证
Verify
描述那些能保证遵照已建立的过程进行活动的措施，一般包括管理者和质量保证部门所做的评审和审计。
37.   高级经理
Senior Management
高级经理在组织的足够高的层次上履行管理任务，主要关注组织的长期生存力，而不承担项目和合同关心的事项和压力。如：项目总监，研发中心主任，软件项目总监。
38.   项目经理
Project Manager
项目经理履行的任务是对整个项目的业务负责，是指导、控制、管理和调整项目进行构造软件或硬件/软件系统工作的个人，项目经理是最终向客户负责的个人。
39.   软件产品
Software Product
指定交付给客户或最终用户的一套完整的计算机程序、规程以及相关的文档和数据。
40.   其他相关组
Other Related Group
指非活动主体本身，但与活动结果有直接及间接关系的组。
41.   一线软件经理
First-line Software Manager
一线软件经理履行的任务是对由软件工程师和其它有关人员组成的一个机构单位（例如，一个部门或者项目组）的人员配置和活动负直接管理责任（包括提供技术方向及对人员和薪金进行管理的功能）。
42.   软件作业领导
Software Task Leader
一个软件作业领导履行的任务是充当特定作业的技术组的领导者，负有技术责任并向工作在该作业的职员提供技术方向。软件作业领导通常和其它工作在该作业的人员一样向同一个一线软件经理报告。

工件类术语
见《研发中心工件表》。

过程类术语
43.   基线
Baseline
已通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能通过正式程序，例如：变更管理和配置控制才能进行更改。
44.   变更管理
Change Management
来管理软件系统开发过程中（从需求到发布）的变更的方法。变更管理贯穿整个开发生命周期，确定如何管理对需求、设计模型、文档、构件、测试用例和源代码的变更
45.   配置项
Configuration Item
软件配置是指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项(configuration item)。
46.   配置标识
Configuration Identification
配置标识活动是对组成基线的配置项进行描述的过程。配置标识活动应该包括配置项选择，配置项命名、配置项描述及各种软件库的建立。
47.   开发库
Development Library
开发库是指在软件生命周期的某一个阶段内，存放与该阶段软件开发工作有关的计算机可读信息和人工可读信息的库。
48.   受控库
Controlled Library
受控库是指在软件生命周期的某一个阶段结束时，存放作为阶段产品而释放的、与软件开发工作有关的计算机可读信息一人工可读信息的库。软件配置管理就是对软件受控库中的各软件项进行管理，因此软件受控库也叫做软件配置管理库。
49.   发布库
Release Library
发布库是指在软件生命周期的组装与系统测试阶段结束后，存放最终产品而后交付给用户运行或在现场安装的软件的库。
50.   对象模型
Object Model
描述实体对象及各个实体对象之间的关系的模型。
51.   工件
Artifact/Work Product
项目中各个环节所产生的结果的统称。CMM中名称为：工作产品
52.   设计
Design
根据软件需求的分析结果进行项目的整体概要设计和详细设计，搭建项目框架并建立其内部的各种关联。
53.   开发案例
描述要在项目中遵循的开发流程，一般是根据历史数据和经验建立的。项目制定开发案例的目的是记录项目的定制流程。
54.   业务需求
Business Requirement
对应于CMM的软件分配需求（Software Allocated Requirement）。
55.   软件需求
Software Requirement
用户为解决一个问题或实现一个目标要求软件一定得满足的条件或能力。
56.   系统需求
System Requirement
一个系统或系统成分为实现用户在解决一个问题时所需要的条件或能力而必须满足或具有的条件或能力。
57.   分析类
代表系统中具备职责和行为的事物的早期概念模型。
58.   设计类
即类，是对具有相同职责、关系、操作、属性和语义的一组对象的说明。
59.   构件
Component
代表一段软件代码（源代码、二进制代码或可执行代码），或包含信息的文件（例如，startup 文件或 ReadMe 文件）。构件同样也可以是其他构件的集合，例如由若干可执行程序组成的应用程序。
60.   规模
Size
具体指某一工件的大小，如代码行、功能点等。
61.   工作量
Effort
工作产品的规模反映到具体人实现时即为工作量，如人/日。
62.   代码行
Line of Code
除去注释、空行等实际可执行的代码行数。
63.   验收准则
Acceptance Criterion
工件完成或一个过程结束时的检查要点。
64.   风险
Risk
风险是任何可能妨碍成功的因素，并且当前是未知的或不确定的。
65.   约定
Commitment
描述组织保证过程得以建立和继续起作用所必须采取的行动，一般包含指定组织的方针和规定，高级管理者的支持，这些行动主要牵涉到企业范围的政策和高层管理的责任。
66.   关键计算机资源
Critical Computer Resource
在目标环境、集成和测试环境中，制约软件工作产品规模、软件运行负载和通信量的软件硬件资源。
67.   软件项目
Software Project
是一项要求共同努力完成的软件开发任务，其目标是开发和维护一个具体的软件产品。
68.   里程碑
Milestone
预先设定的一个阶段正式结束的时间点。
69.   审批
对下级呈报上级的文档或工件进行批示，表示对所审工件的认可或否决意见的权力，角色一般为具有最终决定权的高级经理，属于特定的质量关口，必须签字通过。
70.   评审
Review
评审是一项集体活动，目的是要找出工件中存在的缺陷并评估质量
71.   审定
表示对特定工件的范围、规模、缺陷、质量等方面发表意见，可采用讨论会的形式，无须签字，也不代表需要对该工件负责。
72.   审计
Audit
在软件工程中,为评估是否符合软件需求,规格说明、基线、标准、过程、指令、代码以及合同和特许要求而进行的一种独立的检查。
通过调查研究已制定的过程、指令、规格说明、代码和标准或其它适用的合同特许要求是否恰当和被遵守，以及实现是否有效而进行的活动。
73.   用户需要
NEED
必须解决的业务或运作问题（或能够带来的商机），以此证明购买或使用物有所值。
74.   系统特性
FEAT
一种从外部可见的服务，它由系统提供并用于直接满足用户需要。
75.   用例
UC
系统执行的一系列动作，这些动作将生成特定主角可观测的结果值。往往体现系统的主体功能性需求。
76.   补充需求
SUPP
指那些在用例模型的用例中不容易体现出来的系统需求。
77.   请求
REQ
来自用户的任意类型的请求，例如：变更请求、扩展请求、需求变更请求、缺陷等等。

机构类术语
78.   研究开发中心
Research and Development Center
R&D Center
公司的软件技术研究与应用软件开发的机构。
79.   方案实施部
Plan Implementation Department
公司的一个部门，负责为用户提供整体解决方案及组织方案实施，直属营销中心领导。
80.   产品部
Product Department
公司职能部门，主要负责界定产品业务范围，产品定位，获取和界定产品的业务需求，执行产品部署。
81.   分析设计部
Analysis and Design Department
主要负责和承担公司各个项目的需求定义、分析和设计任务，并为项目的开发技术负责。
82.   开发部
Development Department
职能部门，负责：对照实施子系统的分层结构定义代码结构；以构件（源文件、二进制文件、可执行文件以及其他文件等）的方式实施类和对象；对已开发的构件按单元来测试；将各开发员（或团队）完成的结果集成到可执行系统中。
83.   测试组
Testing Group
职能部门，负责：核实对象之间的交互。核实软件的所有构件是否正确集成。核实所有需求是否已经正确实施。确定缺陷并确保在部署软件之前将缺陷解决。
84.   软件质量保证组
Software Quality Assurance Group
SQA Group
负责对软件项目进行过程审计和工件审计的组。直接向高级经理负责。简称SQA组
85.   软件配置管理组
Software Configuration Management Group
软件配置管理组隶属于公司信息中心，它主要负责研发中心所有项目和产品的软件配置管理工作。
86.   配置控制委员会
Configuration Controlling Board
CCB
是一个组织机构，批准建立软件基线和管理软件基线的变更
87.   信息中心
Information Center
担负公司网络维护和系统安全职责的机构。它独立于研发中心，由公司总载直接领导。
88.   系统工程组
System Engineering Group
负责一个项目的承接和实施组织（即项目跟踪、商务谈判、分配系统需求、项目实施、服务支持）的工作团队。
89.   软件工程组
Software Engineering Group
软件工程组是负责一个项目的软件开发和维护活动（即需求分析、设计、编码和测试）的个人（既有经理又能技术人员）的集团。进行软件有关工作的组，例如软件质量保证组、软件配置管理组和软件工程过程组，不在软件工程组之列。这些组都是“其它软件有关组”。
90.   管理指导委员会
Management Steering Group
MSG
是一个常设的委员会，成员通常由高级经理和其他管理的团队的成员构成，定期地召开有关SPI计划的会议。简称MSG。
91.   软件工程过程组
Software Engineering Process Group
SEPG
负责推进组织的软件过程的定义、维护和改进工作的组，直接向研发中心主任负责。简称SEPG。

角色类术语
见《研发中心角色职责表》。
92.   评审员
Reviewer
评审员负责在项目生命周期中评估项目工件。
在评审会议中，评审员的重点是查找工件的缺陷。
93.   读者
Reader
在评审中，读者的角色由评审员来扮演,在评审会进行期间，读者对被评审工件用自已的话作出解释，有利于发现二义性或可能的错误。
94.   记录员
Recorder
评审会议时，用标准化的形式记录在评审会中提出的问题和缺陷，并将记录结果发给评审员的人员。
95.   协调者
Moderator
在评审中，与作者一起为评审制定计划,协调相关活动,并且保证评审会的进行。
96.   作者
Author
在评审中，作者是创建或维护正在被评审的工件的人员。

CMM术语表详细说明相关推荐

Google发布机器学习术语表 (中英对照）
来源 | TensorFlow Google 工程教育团队已经发布了多语种的 Google 机器学习术语表,该术语表中列出了一般的机器学习术语和 TensorFlow 专用术语的定义.语言版本包括西班 ...
干货丨谷歌最新机器学习术语表
作者:思颖来源:雷锋网日前,谷歌发布机器学习术语表,以下术语表中列出了一般的机器学习术语和 TensorFlow 专用术语的定义. A A/B 测试 (A/B testing) 一种统计方 ...
【转】SharePoint 术语表
术语表术语定义访问控制条目安全对象的自由访问控制列表 (DACL) 或对象的系统访问控制列表 (SACL) 中的一项.在 DACL 中,该项向用户或组授予权限或者拒绝向用户或组授予权限.在 ...
【英语学习】【科学】【Glencoe Science】【D】Human Body Systems 目录及术语表
Table of Contents 简要目录(Simple Contents) 详细目录(Detailed Contents) 术语表(Glossary in Alphabetic Order) 术语 ...
【英语学习】【科学】【Glencoe Science】【C】Animal Diversity 目录及术语表
Table of Contents 简要目录(Simple Contents) 详细目录(Detailed Contents) 术语表(Glossary in Alphabetic Order) 术语 ...
【英语学习】【科学】【Glencoe Science】【B】From Bacteria to Plants 目录及术语表
本文是英语学习笔记,所有版权归原教材作者所有. Glencoe Science模块系列教材,模块B - From Bacteria to Plants,2005版,215页.全书分为5大章(Chapt ...
【英语学习】【科学】【Glencoe Science】【A】Life's Structure and Function目录及术语表
本文是英语学习笔记,所有版权归原教材作者所有. Glencoe Science模块系列教材,模块A - Life's Structure and Function,2005版,254页.全书分为6大章 ...
Google 机器学习术语表
原文:Google机器学习术语表机器学习术语表本术语表中列出了一般的机器学习术语和 TensorFlow 专用术语的定义. A A/B 测试 (A/B testing) 一种统计方法,用于将两种或 ...
【不全】网络工程师术语表
术语表访问控制项(Access Control Entry, ACE) 访问控制列表(ACL)中的一条独立的陈述. 访问控制列表 (Access Control List, ACL) Cisco ...
汇总: 机器学习术语表
来源:https://developers.google.cn/machine-learning/glossary/?hl=zh-CN (中文) https://developers.google.c ...

CMM术语表详细说明

CMM术语表详细说明相关推荐

最新文章

热门文章