版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型自动分支、演进。除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段，我们还需要定义、收集一些元数据（Metadata）来记录版本的辅助信息和规范开发流程，并为今后对软件过程的度量做好准备。当然如果选用的工具支持的话，这些辅助数据将能直接统计出过程数据，从而方便我们软件过程改进（Software Process Improvement，SPI）活动的进行。
对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。一般来说，对于基线版本之前的各个版本都应处于被锁定的状态，如需要对它们进行变更，则应按照变更控制的流程来进行操作。
4．变更控制
在对SCI的描述中，我们引入了基线的概念。从IEEE对于基线的定义中我们可以发现，基线是和变更控制紧密相连的。也就是说在对各个SCI做出了识别，并且利用工具对它们进行了版本管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就成为了软件配置管理的另一重要任务。因此，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的机制。
在本文的前面的部分中，已经把SCI分为基线配置项和非基线配置项两大类，所以这里所涉及的变更控制的对象主要指配置库中的各基线配置项。
变更管理的一般流程是：
A) （获得）提出变更请求；
B) 由CCB审核并决定是否批准；
C) （被接受）修改请求分配人员为，提取SCI，进行修改；
D) 复审变化；
E) 提交修改后的SCI；
F) 建立测试基线并测试；
G) 重建软件的适当版本；
H) 复审（审计）所有SCI的变化；
I) 发布新版本。
在这样的流程中，CMO通过软件配置管理工具来进行访问控制和同步控制，而这两种控制则是建立在前文所描述的版本控制和分支策略的基础上的。
5．状态报告
配置状态报告就是根据配置项操作数据库中的记录来向管理者报告软件开发活动的进展情况。这样的报告应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。
配置状态报告应根据报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。同时也能从中根据开发人员对配置项的操作记录来对开发团队的工作关系作一定的分析。
配置状态报告应该包括下列主要内容：
A) 配置库结构和相关说明；
B) 开发起始基线的构成；
C) 当前基线位置及状态；
D) 各基线配置项集成分支的情况；
E) 各私有开发分支类型的分布情况；
F) 关键元素的版本演进记录；
G) 其它应予报告的事项。