A. 配置管理的作用是什么 包括那几部分功能
作用：通过配置管理，网络管理员可以方便地查询网络当前的配置情况，增强对网络配置的控制。
主要功能：
A． 设置开放系统中有关路由操作的参数
B． 被关对象和被关对象组属性的管理
C． 初始化和关闭被管理对象
D． 根据要求收集系统当前状态的有关信息
E． 获得系统主要变化的信息，维护最新的设备清单并根据数据产生报告。
F． 更该系统的配置，提供远程修改设备配置的手段
注：您这个问题是今年电大计算机网络的考题吧。其实《计算机网络》课程考一道《网络管理》的题，实在不咋地，虽然教材中有这部分内容（本来就不该有），但不属于重点内容，尤其不能占考卷的10%。出题教师太不认真。
B. 啥是配置管理
配置管理（Configuration Management，CM）是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在 软件生命周期 中各个阶段都能得到精确的产品配置。
配置控制重点关注可交付成果及各个过程的技术规范，而变更控制则着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更。
配置管理可以分为三步：
一、识别配置项。找到是哪些功能有改动？
二、记录并报告配置项状态。记录并报告那些功能现在的状态。
三、配置项核实与审计。用那些因素现在的状态和以前的状态进行对比，确定原本计划调整的功能否有更改、是否落实。
软件配置管理 的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求驱动下不断变化，为了保证对产品有效地进行控制和追踪，配置管理过程不能仅仅对静态的、成形的产品进行管理，而必须对动态的、成长的产品进行管理。由此可见，配置管理同软件开发过程紧密相关。配置管理必须紧扣软件开发过程的各个环节：管理用户所提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本中去，并在产品发行和用户支持等方面提供帮助，响应用户新的需求，推动新的开发周期。
配置管理通俗点说就是：你要变更，好，你变哪了咋变的，你万一骗我呢。我要去查查看看你说的和你做的一致么。
配置管理系统和变更管理系统之间的关系如下图：
C. CMMI中的的配置管理是什么
配置管理是CMMI模型中一个支撑过程域。
配置管理是指：应用技术和管理手段来识别和记录配置项的功能和物理特性，控制其变更，记录和报告变更的过程和实现状态，并检查与项目需求之间的符合度；通过配置管理可以有效的管理工作产品与工作产品之间的一致性，合理的控制和实施变更以维护对项目范围与边界条件的一致的理解。
一般CM过程描述了配置管理活动的内容、规范和方法，以建立和维护软件开发过程中各种产品的完整性和一致性。
CM使用到以下几个重要的术语：
配置项：处于配置管理之下的软件或/和硬件的集合体。这个集合体在配置管理过程中作为一个实体出现。
基线： 已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式变更控制过程来改变；基线有一组配置组成，这些配置构成了一个相对稳定的状态，不能再被任何人随意修改。
配置标识：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
控制：通过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。
状态统计：记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。
配置审计：通过第三方（例如：软件质量保证工程师）来确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合；
配置管理员：根据本过程的规定，在本公司内部具体实施与操作本过程的人员/角色。根据实施的层级的不同，配置管理员可以区分为“产品配置管理员”和“项目配置管理员”两个角色，一般产品配置管理员是专职的，项目配置管理员有项目成员兼职。
D. 什么是配置项管理
按管理的严格程度，配置项一般分3个等级：
（1）纳入基线管理的配置项
纳入基线管理的配置项是指变化时要走严格变更手续的配置项，需要做变更申请，要审批。审批一般分2种严格程度：
i) 项目经理或分CCB审批就可以，一般是局部的小的变更。
ii）变更控制委员会（CCB）审批
纳入基线前，一般要经过评审或测试（称为验证）和质量保证。
(2) 没有纳入基线但是也不能随意变更的配置项，一般称为受控项
这类配置项不需要变更申请，但是要经过配置管理员或项目经理的允许才可以变更。
基线项与受控项写的权限要唯一，一般是CM或PM有唯一的写权限。
（3）非受控项
对变更不做控制。
拟纳入基线管理的配置项状态变化一般是先非受控，然后受控，最后基线化。变更时，先检出（checkou）进行修改，修改完毕后再检入（checki）转为受控，等待验证（测试或评审），通过验证后进行基线化。
拟纳入受控而不入基线的配置项状态变化一般是先非受控，然后受控。变更时，检出进行修改，修改完毕后再检入提交受控。
纳入基线管理的时机是管理平衡问题，一般是当配置项基本稳定后才纳入基线管理，如果处与频繁的变动之中，纳入基线后会增加管理成本，如单元测试通过后一般不形成基线，因为此时代码并不稳定，但是可以作为受控项，也不能任意变化。这个问题的判断也和项目组的规模有关系，如果规模很大，涉及到的人员很多，也可能需要建立基线。在系统测试后要形成基线，一般称为产品基线，此时系统基本稳定了，可以对外发布，为更多的人所了解和使用了。代码在没有纳入基线但是受控后（提交测试人员测试了），也不能随便变更了，要经过配置管理员的批准，并通知测试人员。