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

第17章 配置管理217.1 介绍217.2 制订配置管理计划417.2.1 目标417.2.2 角色和职责417.2.3 开启准则417.2.4 输入417.2.5 关键步骤4Step1 确定配置管理软硬件资源4Step2 制订配置项计划5Step3 制订基线计划5Step4 制订配置库备份计划5Step5 审批配置管理计划517.2.6 输出517.2.7 结束准则617.2.8 度量617.3 配置库管理617.3.1 目标617.3.2 角色和职责617.3.3 开启准则617.3.4 输入617.3.5 关键步骤6Step1 创建配置库6Step2 分配权限7Step3 配置库操作和管理717.3.6 输出717.3.7 结束准则717.3.8 度量717.3 版本控制717.3.1 目标717.3.2 角色和职责817.3.3 配置项状态变迁规则817.3.4 配置项版本号规则817.3.4 配置项版本控制步骤9Step1 创建配置项9Step2 修改处于“初稿”状态配置项9Step3 技术评审或领导审批9Step4 正式公布9Step5 变更917.4 配置项变更控制917.4.1 目标917.4.2 角色和职责1017.4.3 开启准则1017.4.4 输入1017.4.5 关键步骤10Step1 变更申请10Step2 审批变更申请10Step3 安排变更任务10Step4 实施变更任务10Step5 对更改后配置项重新进行技术评审（或审批）10Step6 结束变更1117.4.6 输出1117.4.7 结束准则1117.4.8 度量1117.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-TypeType-Number。 能够在Project（或Product）前面加上企业标识符。 TypeType表示配置项类型，能够采取多级缩写。 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 选择适宜软件工具，尽可能降低配置管理过程工作量。