文档介绍：第17章 配置治理 2
介绍 2
制定配置治理筹划 4
目的 4
脚色与职责 4
启动准则 4
输入 4
主要步调 4
[Step1] 确定配置治理的软硬件资源 4
[Step2] 制定配置项筹划 5
[Step3] 制定基线筹划 5
[Step4] 制定配置库备份筹划 5
[Step5] 审批《配置治理筹划》 5
输出 5
结束准则 6
度量 6
配置库治理 6
目的 6
脚色与职责 6
启动准则 6
输入 6
主要步调 6
[Step1] 创建配置库 6
[Step2] 分派权限 7
[Step3] 配置库操纵与治理 7
输出 7
结束准则 7
度量 7
版本控制 7
目的 7
脚色与职责 8
配置项状态变迁规矩 8
配置项版本号规矩 8
配置项版本控制流程 9
[Step1] 创建配置项 9
[Step2] 修改处于“草稿”状态的配置项 9
[Step3] 技能评审或领导审批 9
[Step4] 正式公布 9
[Step5] 变动 9
配置项变动控制 9
目的 9
脚色与职责 10
启动准则 10
输入 10
主要步调 10
[Step1] 变动申请 10
[Step2] 审批变动申请 10
[Step3] 摆设变动任务 10
[Step4] 执行变动任务 10
[Step5] 对变动后的配置项重新进行技能评审（或审批） 10
[Step6] 结束变动 11
输出 11
结束准则 11
度量 11
实施发起 11
第17章 配置治理
配置治理（Configuration Management, CM）的目的是通过执行版本控制、变动控制等规程，以及使用配置治理软件，来包管所有配置项的完整性和可跟踪性。配置治理是对事情结果的一种有效掩护。
配置治理历程域是SPP模型的重要组成部门。本范例论述了配置治理历程域的四个主要规程：
制定配置治理筹划 [SPP-PROC-CM-PLANNING]
配置库治理 [SPP-PROC-CM-LIB]
配置项版本控制 [SPP-PROC-CM-VERSION]
配置项变动控制 [SPP-PROC-CM-CHANGE]
上述每个规程的“目标”、“脚色与职责”、“启动准则”、“输入”、“主要步调”、“输出”、“完成准则”和“度量”均已界说。
本范例适用于海内IT企业的软件研发项目。发起用户凭据自身情况（如商业目标、研发实力等）适本地修改本范例，然后推广使用。
介绍
项目研发和治理历程中会产生许许多多的事情结果，例如文档、步伐和数据等，它们都应当被生存起来，以便查阅和修改。如果把所有文件一股脑地塞进盘算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地生存起来。
通常纳入配置治理领域的事情结果统称为配置项（Configuration Item, CI），配置项主要有两大类：
（1）属于产物组成部门的事情结果，例如需求文档、设计文档、源代码、测试用例等。
（2）项目治理和机构支撑历程域产生的文档。这些文档虽然不是产物的组成部门，但是值得生存。
每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被生存在配置库里，确保不会殽杂、丢失。配置项及其历史记载反应了软件的演化历程。
基线（Baseline）由一组配置项组成，这些配置项组成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变动控制规程）。基线通常对应于开发历程中的里程碑（Milestone），一个产物可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。
所有的项目成员都要使用配置治理软件来掩护自己的事情结果。机构应当接纳统一的配置治理软件，常见的配置治理软件有Microsoft的Visual SourceSafe和Rational的ClearCase等。为了提高配置治理的效率和宁静性，机构应当有专门的配置治理员（
脚色）。配置治理员为每个项目制定《配置治理筹划》，创建和维护配置库。
鉴于配置治理的重要性和庞大性，机构还应当设立配置控制委员会（Configuration Control Board, CCB）。CCB是个虚拟小组，对配置治理各项运动拥有决策权（例如审批筹划，审批变动请求等）。对付配置治理而言，CCB是决策者，而配置治理员是执行者。
如果机构的各个项目紧密相关（例如一个产物线下的多个项目），发起机构设立大