第17章 配置管理
第17章 配置管理 2 17.1 介绍 2 17.2 制定配置管理计划 4 17.2.1 目的 4 17.2.2 角色与职责 4 17.2.3 启动准则 4 17.2.4 输入 4 17.2.5 主要步骤 4 [Step1] 确定配置管理的软硬件资源 4 [Step2] 制定配置项计划 5 [Step3] 制定基线计划 5 [Step4] 制定配置库备份计划 5 [Step5] 审批《配置管理计划》 5 17.2.6 输出 5 17.2.7 结束准则 6 17.2.8 度量 6 17.3 配置库管理 6 17.3.1 目的 6 17.3.2 角色与职责 6 17.3.3 启动准则 6 17.3.4 输入 6 17.3.5 主要步骤 6 [Step1] 创建配置库 6 [Step2] 分配权限 7 [Step3] 配置库操作与管理 7 17.3.6 输出 7 17.3.7 结束准则 7 17.3.8 度量 7 17.3 版本控制 7 17.3.1 目的 7 17.3.2 角色与职责 8 17.3.3 配置项状态变迁规则 8 17.3.4 配置项版本号规则 8 17.3.4 配置项版本控制流程 9 [Step1] 创建配置项 9 [Step2] 修改处于“草稿”状态的配置项 9 [Step3] 技术评审或领导审批 9 [Step4] 正式发布 9 [Step5] 变更 9 17.4 配置项变更控制 9 17.4.1 目的 9 17.4.2 角色与职责 10 17.4.3 启动准则 10 17.4.4 输入 10 17.4.5 主要步骤 10 [Step1] 变更申请 10 [Step2] 审批变更申请 10 [Step3] 安排变更任务 10 [Step4] 执行变更任务 10 [Step5] 对更改后的配置项重新进行技术评审（或审批） 10 [Step6] 结束变更 11 17.4.6 输出 11 17.4.7 结束准则 11 17.4.8 度量 11 17.5 实施建议 11 第17章 配置管理 配置管理（Configuration Management, CM）的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所 有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。 配置管理过程域是SPP模型的重要组成部分。本规范阐述了配置管理过程域的四个主 要规程： ← 制定配置管理计划 [SPP-PROC-CM-PLANNING] ← 配置库管理 [SPP-PROC-CM-LIB] ← 配置项版本控制 [SPP-PROC-CM-VERSION] ← 配置项变更控制 [SPP-PROC-CM-CHANGE] 上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出 ”、“完成准则”和“度量”均已定义。 本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研 发实力等）适当地修改本规范，然后推广使用。 17.1 介绍 项目研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们 都应当被保存起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使 用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。 凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item, CI），配置项主要有两大类： （1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。 （2）项目管理和机构支撑过程域产生的文档。这些文档虽然不是产品的组成部分，但是 值得保存。 每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配 置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演 化过程。 基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。 基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。基线通常 对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个 基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称 为一个“Release”，为内部开发用的基线则称为一个“Build”。 所有的项目成员都要使用配置管理软件来保护自己的工作成果。机构应当采用统一的 配置管理软件，常见的配置管理软件有Microsoft的Visual SourceSafe和Rational的ClearCase等。为了提高配置管理的效率和安全性，机构应当有 专门的配置管理员（角色）。配置管理员为每个项目制定《配置管理计划》，创建和维护 配置库。 鉴于配置管理的重要性和复杂性，机构还应当设立配置控制委员会（Configuration Control Board, CCB）。CCB是个虚拟小组，对配置管理各项活动拥有决策权（例如审批计划，审批变更 请求等）。对于配置管理而言，CCB是决策者，而配置管理员是执行者。 如果机构的各个项目紧密相关（例如一个产品线下的多个项目），建议机构设立公共 的CCB，这个公共的CCB对所有项目的配置管理拥有决策权。如果机构的各个项目相对独 立，那么每个项目可以设立各自的CCB。CCB的决策采用“少数服从多数”原则。 配置管理的流程如图17-1所示。 图17-1 配置管理流程图 一、制定配置管理计划 配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、 基线计划、交付计划、备份计划等。CCB审批该计划。 二、配置库管理 配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的 权限操作配置库。配置管理员定期维护配置库，例如清楚垃圾文件、备份配置库等。 三、版本控制 在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配 置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比老版本“好”，所以 不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生 版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。 配置项的状态有三种：“草稿”、“正式发布”和“正在修改”，本规程制定了配置项状态 变迁与版本号的规则。 四、变更控制 在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防 止配置项被随意修改而导致混乱。 修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制 规则执行即可。 当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必 须依据“申请－审批－执行变更－再评审－结束”的规则执行。 五、配置审计 为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量 保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证 人员的工作职责之一。请参考质量保证规范SPP-PROC-QA，此处不再论述。 配置管理过程域产生的主要文档有： ← 《配置管理计划》，模板见 [SPP-TEMP-CM-PLAN]。 ← 《配置库管理报告》，模板见 [SPP-TEMP-CM-LIB]。 ← 《配置项变更控制报告》，模板见 [SPP-TEMP-CM-CHANGE]。 17.2 制定配置管理计划 17.2.1 目的 o 制定配置管理计划，以便有计划地开展配置管理工作。 17.2.2 角色与职责 o 配置管理员制定《配置管理计划》。 o CCB审批《配置管理计划》。CCB的人数视项目的规模而定。通常CCB由项目经理、资深项 目成员等人组成，项目经理为CCB负责人。CCB的决策采用“少数服从多数”原则。 17.2.3 启动准则 o 《项目计划》已经制定 o 配置管理员和CCB已经确定。 17.2.4 输入 o 《项目计划》 17.2.5 主要步骤 [Step1] 确定配置管理的软硬件资源 o 配置管理员根据项目的规模以及财力，确定配置管理软件以及计算机资源（考虑内存、 外存、CPU等）。常用的配置管理软件有Microsoft公司的Visual SourceSafe和Rational公司的ClearCase等。 [Step2] 制定配置项计划 o 配置管理员识别项目的主要配置项。每个配置项都有唯一的标识符，标识符的参考格式 为Project-Type…Type-Number。 ← 可以在Project（或Product）前面加上公司的标识符。 ← Type…Type表示配置项类型，可以采用多级缩写。 ← Number为3为数字，范围从001到999，表示一个配置项有若干个文件。若配置项只 有一个文件，则该项可以省略。 o 配置项计划的参考格式如下： |类型 |主要配置项 |标识符 |预计正式发布时间| | | | | | | | | | | [Step3] 制定基线计划 o 配置管理员确定每个基线的名称（标识符）及其主要配置项，估计每个基线建立的时间 。基线计划的参考格式如下： |基线名称/标识符 |基线所包含的主要配置项 |预计建立时间 | | | | | | | | | [Step4] 制定配置库备份计划 o 配置管理员制定配置库备份计划，指明“何人”在“何时”（频度）将配置库备份到“何处 ”。 [Step5] 审批《配置管理计划》 o CCB审批《配置管理计划》。若该计划被批准，则请CCB负责人签字认可。否则，配置管理 员按照CCB的意见修改《配置管理计划》，直到该计划被批准为止。 17.2.6 输出 o 《配置管理计划》 17.2.7 结束准则 o 《配置管理计划》已经制定并被CCB的批准。 17.2.8 度量 o 配置管理统计工作量以及文档的规模，汇报给项目经理。 17.3 配置库管理 17.3.1 目的 o 所有人员依照配置管理规范和《配置管理计划》操作配置库。 17.3.2 角色与职责 o 配置管理创建并维护配置库。 o 项目成员在权限之内操作配置库。 17.3.3 启动准则 o 《配置管理计划》已经制定。 o 配置管理的软件硬件已经存在。 17.3.4 输入 o 《配置管理计划》 17.3.5 主要步骤 [Step1] 创建配置库 o 配置管理员创建配置库，并且至少创建配置库的所有第一级目录。 [Step2] 分配权限 o 配置管理员为每个项目成员分配操作权限。一般地，项目成员拥有Add, Checkin/Checkout, Download等权限，但是不能拥有“删除”权限。配置管理员的权限最高。具体操作视所 采用的配置管理软件而定。 [Step3] 配置库操作与管理 o 项目成员根据自己的权限操作配置库，例如Add, Checkin/Checkout, Download等。 o 配置管理员根据“基线计划”创建与维护基线，“冻结”配置项，控制变更。 o 配置管理员定期清除配置库里的垃圾文件。 o 配置管理员定期备份配置库。 o 交付管理。这里“交付”是指从配置库中提取配置项，交付给客户或项目外的人员。交付 出去的配置项必须有据可查，避免发生混乱。流程如下： 1. “索取人”向CCB提出交付申请。 2. CCB审批该申请。如果该申请不合法（合理），则拒绝交付配置项。如果同意交付 ，CCB应给出详细的交付清单。 3. 配置管理员依据CCB的批示，从配置库中提取配置项交付给“索取人”。 4. “索取人”验收后签字。 17.3.6 输出 o 《配置库管理报告》（由配置管理员撰写） 17.3.7 结束准则 o 对配置库的操作与管理将持续到项目结束。 17.3.8 度量 o 配置管理员统计工作量以及文档规模。 17.3 版本控制 17.3.1 目的 o 按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快 速准确地查找到配置项的任何版本。 17.3.2 角色与职责 o 所有项目成员都必须遵照版本控制规程操作配置库。 17.3.3 配置项状态变迁规则 配置项的状态有三种：“草稿”（Draft）、“正式发布”（Released）和“正在修改”（ Changing）。 配置项状态变迁如图17- 2所示。配置项刚建立时其状态为“草稿”。配置项通过评审（或审批）后，其状态变为“ 正式发布”。此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改 ”。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循 环。 图17-2 配置项状态变迁图 17.3.4 配置项版本号规则 配置项的版本号与配置项的状态紧密相关： （1）处于“草稿”状态的配置项的版本号格式为：0.YZ ← YZ数字范围为01-99。 ← 随着草稿的不断完善，“YZ”的取值应递增。“YZ”的初值和增幅由用户自己把握。 （2）处于“正式发布”状态的配置项的版本号格式为：X.Y ← X为主版本号，取值范围为1-9。Y为次版本号，取值范围为1-9。 ← 配置项第一次“正式发布”时，版本号为1.0。 ← 如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置 项版本升级幅度比较大时，才允许增大X值。 （3）处于“正在修改”状态的配置项的版本号格式为：X.YZ ← 配置项正在修改时，一般只增大Z值，X.Y值保持不变。 ← 当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。参 见规则（2）。 17.3.4 配置项版本控制流程 [Step1] 创建配置项 o 项目成员依据《配置管理计划》，在配置库中创建属于其任务范围内的配置...
第17章 配置管理