企业配置管理方案研究样本.doc

第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”。
全部项目组员全部要使用配置管理软件来保护自己工作结果。机构应该采取统一配置管理软件，常见配置管理软件有MicrosoftVisual SourceSafe和RationalClearCase等。为了提升配置管理效率和安全性，机构应该有专门配置管理员（角色）。配置管理员为每个项目制订《配置管理计划》，创建和维护配置库。
鉴于配置管理关键性和复杂性，机构还应该设置配置控制委员会（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 目标
l 制订配置管理计划，方便有计划地开展配置管理工作。
17.2.2 角色和职责
l 配置管理员制订《配置管理计划》。
l CCB审批《配置管理计划》。CCB人数视项目标规模而定。通常CCB由项目经理、资深项目组员等人组成，项目经理为CCB责任人。CCB决议采取“少数服从多数”标准。
17.2.3 开启准则
l 《项目计划》已经制订
l 配置管理员和CCB已经确定。
17.2.4 输入
l 《项目计划》
17.2.5 关键步骤
[Step1] 确定配置管理软硬件资源
l 配置管理员依据项目标规模和财力，确定配置管理软件和计算机资源（考虑内存、外存、CPU等）。常见配置管理软件有Microsoft企业Visual SourceSafe和Rational企业ClearCase等。
[Step2] 制订配置项计划
l 配置管理员识别项目标关键配置项。每个配置项全部有唯一标识符，标识符参考格式为Project-Type…Type-Number。
² 能够在Project（或Product）前面加上企业标识符。
² Type…Type表示配置项类型，能够采取多级缩写。
² Number为3为数字，范围从001到999，表示一个配置项有若干个文件。若配置项只有一个文件，则该项能够省略。
l 配置项计划参考格式以下：

类型
关键配置项
标识符
估计正式公布时间

[Step3] 制订基线计划
l 配置管理员确定每个基线名称（标识符）及其关键配置项，估量每个基线建立时间。基线计划参考格式以下：

基线名称/标识符
基线所包含关键配置项
估计建立时间

[Step4] 制订配置库备份计划
l 配置管理员制订配置库备份计划，指明“何人”在“何时”（频度）将配置库备份到“何处”。
[Step5] 审批《配置管理计划》
l CCB审批《配置管理计划》。若该计划被同意，则请CCB责任人签字认可。不然，配置管理员根据CCB意见修改《配置管理计划》，直到该计划被同意为止。
17.2.6 输出
l 《配置管理计划》
17.2.7 结束准则
l 《配置管理计划》已经制订并被CCB同意。
17.2.8 度量
l 配置管理统计工作量和文档规模，汇报给项目经理。
17.3 配置库管理
17.3.1 目标
l 全部些人员依据配置管理规范和《配置管理计划》操作配置库。
17.3.2 角色和职责
l 配置管理创建并维护配置库。
l 项目组员在权限之内操作配置库。
17.3.3 开启准则
l 《配置管理计划》已经制订。
l 配置管理软件硬件已经存在。
17.3.4 输入
l 《配置管理计划》
17.3.5 关键步骤
[Step1] 创建配置库
l 配置管理员创建配置库，而且最少创建配置库全部第一级目录。
[Step2] 分配权限
l 配置管理员为每个项目组员分配操作权限。通常地，项目组员拥有Add, Checkin/Checkout, Download等权限，不过不能拥有“删除”权限。配置管理员权限最高。具体操作视所采取配置管理软件而定。
[Step3] 配置库操作和管理
l 项目组员依据自己权限操作配置库，比如Add, Checkin/Checkout, Download等。
l 配置管理员依据“基线计划”创建和维护基线，“冻结”配置项，控制变更。
l 配置管理员定时清除配置库里垃圾文件。
l 配置管理员定时备份配置库。
l 交付管理。这里“交付”是指从配置库中提取配置项，交付给用户或项目外人员。交付出去配置项必需有据可查，避免发生混乱。步骤以下：
（1） “索取人”向CCB提出交付申请。
（2） CCB审批该申请。假如该申请不正当（合理），则拒绝交付配置项。假如同意交付，CCB应给出具体交付清单。
（3） 配置管理员依据CCB指示，从配置库中提取配置项交付给“索取人”。
（4） “索取人”验收后签字。
17.3.6 输出
l 《配置库管理汇报》（由配置管理员撰写）
17.3.7 结束准则
l 对配置库操作和管理将连续到项目结束。
17.3.8 度量
l 配置管理员统计工作量和文档规模。
17.3 版本控制
17.3.1 目标
l 根据一定规则保留配置项全部版本，避免发生版本丢失或混淆等现象，而且能够快速正确地查找到配置项任何版本。
17.3.2 角色和职责
l 全部项目组员全部必需遵照版本控制规程操作配置库。
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] 创建配置项
l 项目组员依据《配置管理计划》，在配置库中创建属于其任务范围内配置项。此时配置项状态为“初稿”，其版本号格式为0.YZ。
[Step2] 修改处于“初稿”状态配置项
l 项目组员使用配置管理软件Checkout/Checkin功效，能够自由修改处于“初稿”状态配置项（不受变更控制规程约束），版本号格式为0.YZ。
[Step3] 技术评审或领导审批
l 假如配置项是技术文档，则需要接收技术评审（参见技术评审规程[SPP-PROC-TR]）。假如配置项是“计划”这类文件，则需要项目经理（或上级领导）审批。
l 若配置项经过了技术评审或领导审批，则转向 [Step4]，不然转向 [Step2]。
[Step4] 正式公布
l 配置项经过技术评审或领导审批以后，则配置项状态从“初稿”变迁为“正式公布”，版本号格式为X.Y。
[Step5] 变更
l 修改处于“正式公布”状态配置项，必需根据“变更控制规程”实施，关键步骤以下（详见变更控制规程）：
² 假如CCB同意变更，则配置项状态从“正式公布”变迁为“正在修改”。
² 项目组员使用Checkout/Checkin功效，能够修改处于“正在修改”状态配置项，版本号格式为X.YZ。
² 修改完成后，该配置项要重新接收技术评审或领导审批，转向[Step3]。
17.4 配置项变更控制
17.4.1 目标
l 预防配置项被随意修改而造成混乱。
17.4.2 角色和职责
l CCB对审批变更申请。
17.4.3 开启准则
l 待变更配置项状态为“正式公布”，或该配置项已经成为某个基线一部分（即被“冻结”）。
17.4.4 输入
l 待变更配置项
17.4.5 关键步骤
[Step1] 变更申请
l 变更申请人向CCB提交变更申请，关键说明“变更内容”和“变更原因”。
[Step2] 审批变更申请
l CCB审批该申请，分析此变更对项目造成影响。假如同意变更，则转向 [Step3]，不然终止本规程。
补充说明：一个配置项变更可能造成其它配置项也发生变更，CCB在审批变更申请时一定要考虑这些问题。
[Step3] 安排变更任务
l CCB指定变更实施人，安排她们任务。CCB需要和变更实施人就变更内容达成共识。
补充说明：变更实施人可能是变更申请人，也可能不是。
[Step4] 实施变更任务
l 变更实施人依据CCB安排任务，修改配置项。
l CCB监督变更任务实施，如检验变更内容是否正确、是否按时完成工作等。
[Step5] 对更改后配置项重新进行技术评审（或审批）
l 假如配置项是技术文档，则需要接收技术评审（参见技术评审规程[SPP-PROC-TR]）。假如配置项是“计划”这类文件，则需要项目经理（或上级领导）审批。
l 若配置项经过了技术评审或领导审批，则转向 [Step6]，不然转向 [Step4]（即重新修改）。
[Step6] 结束变更
l 当全部变更后配置项全部经过了技术评审或领导审批，这些配置项状态从“正在修改”变迁为“正式公布”。CCB在《配置项变更控制汇报》中签字，结束变更。
17.4.6 输出
l 本规程全部信息全部统计在《配置项变更控制汇报》中。
17.4.7 结束准则
l CCB签字结束变更。
17.4.8 度量
l CCB统计变更工作量。
17.5 实施提议
l 要求全部些人员对其工作结果进行配置管理。
l 对全员进行配置管理培训。
l 因为配置库里保留是项目标全部工作结果，应该选择“责任心强、可靠”人员担任配置管理员。
l 选择适宜软件工具，尽可能降低配置管理过程工作量。