目前 configuration在国内有两种翻译方法：
在软件行业习惯上叫“配置”
硬件行业更多用“技术状态”
我们不能简单地认为对于H类, 配置管理就是产品结构图+BOM
当然这是H类配置管理的主要配置项,主配置项目可能是:
产品设计档案（机构图纸、电路原理图、电路布线图、源代码、产品开发环境...）、关键零件规格书、BOM、测试用例……
但为了管理产品生命周期，我们会发现一些辅助性的资料/记录/文档，甚至样板也要纳入到配置管理的范围中来，我们就又将另外的一些东西加进来,使之成为一个整体
如:项目计划、测试计划、评审报告、试产报告、项目组成员名单等等。
配置管理的重点是管理配置项的变更,而且是"以产品为核心"来管理配置项的变更，实际就是在管理产品的变更，在进行产品生命周期的记录和追踪。
配置管理主要在软件行业使用广泛,一个最简单的原因是软件版本常比较复杂,甚至通常是一个版本树的结构.
最简单的例子是硬件版本变更通常是直线型的1.0-2.0-3.0-4.0......
并且一般不会退回旧版本.
而软件的版本变更可能是一个树状的结构.
1.0
1.1 1.2
1.3 1.4
2.0
2.1 2.3 2.4
.....
而且因为是智力活动,有时候大家就发现,新版本还不如旧版本,所以又时不时要退回使用旧版本.
但又过了两天发现那个新版本还是不错,再把它调出来看看.
还有种状况是开发团队分布在不同地点，每个组(或成员)在开发各自专业的那部分,如何使他们开发出来的东西能够正确组合在一起呢?
还有就是所有的软件工程师最痛苦做的事情不是编写新程序,而是维护别人写的程序,那就要理解产品的变更历史,摸块的变更状况,否则最后面对只有一个最新的版本的源代码,没有配套的资料,没有任何参考信息,这不是要人命吗?
.....
所以需要一种机制来控制变更,否则谁也不知道哪个版本是最新,哪个版本是可参考,
希望有一种机制来记录产品的生命周期,
这就是配置管理.
配置管理的主要工作是:
A 配置项的选定/标识
B、制定配置管理计划
C、变更管理（主要体现为版本控制）
D、配置审核
E、配置状态报告（国标翻译成了一个拗口的术语：技术状态记实）
对于HS类产品还要考虑硬件和软件的接口(版本配合)。
这应该是在TL9000 7.5.3.HS.1提到的内容
关于CMP,就是在配置管理之前做好计划,如要管理哪些配置项,什么时间开始管理配置项?以什么样的方式来管理配置项?
CMP(Configruation Management Plan)和配置管理所管理的主体-----配置项(CI:Configruation Item)是不一样.
