资源描述
第 17章 配置管理17.1 介绍 217.2 制定配置管理计划 417.2.1 目的 417.2.2 角色与职责 417.2.3 启动准则 417.2.4 输入 417.2.5 主要步骤 4 Step1 确定配置管理的软硬件资源 4 Step2制定配置项计划 5 Step3制定基线计划 5 Step4制定配置库备份计划 5 Step5审批配置管理计划 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.5 配置项版本控制流程 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 ”。所有的项目成员都要使用配置管理软件来保护自己的工作成果。机构应当采用统一的配置管理软件，常见的配置管理软件有Microsoft 的 Visual SourceSafe 和 Rational的 ClearCase 等。 为了提高配置管理的效率和安全性，机构应当有专门的配置管理员（角色）。配置管理员为每个项目制定配置管理计划，创建和维护配置库。鉴于配置管理的重要性和复杂性，机构还应当设立配置控制委员会（ConfigurationControl 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 目的制定配置管理计划，以便有计划地开展配置管理工作。17.2.2 角色与职责配置管理员制定配置管理计划。CCB 审批 配置管理计划。 CCB 的人数视项目的规模而定。通常 CCB 由项目经理、资深项目成员等人组成，项目经理为CCB 负责人。CCB 的决策采用“少数服从多数”原则。17.2.3 启动准则项目计划已经制定配置管理员和CCB 已经确定。17.2.4 输入项目计划17.2.5 主要步骤Step1 确定配置管理的软硬件资源配置管理员根据项目的规模以及财力，确定配置管理软件以及计算机资源（考虑内存、外存、CPU等）。常用的配置管理软件有 和 Rational 公司的 ClearCase 等。Microsoft 公司的 Visual SourceSafeStep2制定配置项计划配置管理员识别项目的主要配置项。每个配置项都有唯一的标识符，标识符的参考格式为 Project-Type Type-Number。可以在Project （或Product）前面加上公司的标识符。Type - Type表示配置项类型，可以采用多级缩写。Number为3为数字，范围从 001到999,表示一个配置项有若干个文件。若配 置项只有一个文件，则该项可以省略。配置项计划的参考格式如下：类型主要配置项标识符预计正式发布时间Step3制定基线计划配置管理员确定每个基线的名称（标识符）及其主要配置项，估计每个基线建立的 时间。基线计划的参考格式如下：基线名称/标识符基线所包含的主要配置项预计建立时间Step4制定配置库备份计划（频度）将配置库备份到CCB负责人签字认可。否则, ,直到该计划被批准为止。配置管理员制定配置库备份计划，指明“何人”在“何时” “何处”。Step5审批配置管理计划CCB审批配置管理计划。若该计划被批准，则请配置管理员按照 CCB的意见修改配置管理计划17.2.6输出配置管理计划17.2.7 结束准则配置管理计划已经制定并被CCB 的批准。17.2.8 度量配置管理统计工作量以及文档的规模，汇报给项目经理。17.3 配置库管理17.3.1 目的所有人员依照配置管理规范和配置管理计划操作配置库。17.3.2 角色与职责配置管理创建并维护配置库。项目成员在权限之内操作配置库。17.3.3 启动准则配置管理计划已经制定。配置管理的软件硬件已经存在。17.3.4 输入配置管理计划17.3.5 主要步骤Step1 创建配置库配置管理员创建配置库，并且至少创建配置库的所有第一级目录。Step2 分配权限配 置 管 理 员 为 每 个 项 目 成 员 分 配 操 作 权 限 。 一 般 地 ， 项 目 成 员 拥 有 Add, Checkin /Checkout, Download 等权限，但是不能拥有“删除”权限。配置管理员的权限最高。具体操作视所采用的配置管理软件而定。Step3 配置库操作与管理项目成员根据自己的权限操作配置库，例如Add, Checkin /Checkout, Download 等。配置管理员根据“基线计划”创建与维护基线， “冻结”配置项，控制变更。配置管理员定期清除配置库里的垃圾文件。配置管理员定期备份配置库。交付管理。这里“交付”是指从配置库中提取配置项，交付给客户或项目外的人员。交付出去的配置项必须有据可查，避免发生混乱。流程如下：（ 1 ） “索取人”向 CCB 提出交付申请。（ 2 ） CCB 审批该申请。如果该申请不合法（合理），则拒绝交付配置项。如果同意交付，CCB 应给出详细的交付清单。（ 3 ）配置管理员依据CCB 的批示，从配置库中提取配置项交付给“索取人”。（ 4） “索取人”验收后签字。17.3.6 输出配置库管理报告（由配置管理员撰写）17.3.7 结束准则对配置库的操作与管理将持续到项目结束。17.3.8 度量配置管理员统计工作量以及文档规模。17.3 版本控制17.3.1 目的按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。17.3.2 角色与职责所有项目成员都必须遵照版本控制规程操作配置库。17.3.3 配置项状态变迁规则配置项的状态有三种："草稿"（Draft）、"正式发布"（Released）和"正在修改”（Changing ）。配置项状态变迁如图17-2所示。配置项刚建立时其状态为“草稿”。配置项通过评审（或审批）后，其状态变为“正式发布” 。此后若更改配置项，必须依照“变更控制规 程”执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。图17-2配置项状态变迁图17.3.4 配置项版本号规则配置项的版本号与配置项的状态紧密相关：（1）处于“草稿”状态的配置项的版本号格式为：0.YZYZ数字范围为 01-99。随着草稿的不断完善，“ YZ ”的取值应递增。“ YZ ”的初值和增幅由用户自己把握。（2）处于“正式发布”状态的配置项的版本号格式为：X.YX为主版本号，取值范围为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 创建配置项项目成员依据配置管理计划，在配置库中创建属于其任务范围内的配置项。此时配置项的状态为“草稿”，其版本号格式为0.YZ 。Step2 修改处于“草稿”状态的配置项项目成员使用配置管理软件的Checkout/ Checkin 功能，可以自由修改处于“草稿”状态的配置项（不受变更控制规程约束），版本号格式为0.YZ 。Step3 技术评审或领导审批如果配置项是技术文档，则需要接受技术评审（参见技术评审规程SPP-PROC-TR ） 。如果配置项是“计划”这类文件，则需要项目经理（或上级领导）的审批。若配置项通过了技术评审或领导审批，则转向Step4 ，否则转向Step2 。Step4 正式发布配置项通过技术评审或领导审批之后，则配置项的状态从“草稿”变迁为“正式发布” ，版本号格式为X.Y 。Step5 变更修改处于“正式发布”状态的配置项，必须按照“变更控制规程”执行，主要步骤如下（详见变更控制规程）：如果 CCB 同意变更，则配置项状态从“正式发布”变迁为“正在修改”。项目成员使用Checkout/ Checkin 功能，可以修改处于“正在修改”状态的配置项，版本号格式为X.YZ 。修改完毕后，该配置项要重新接受技术评审或领导审批，转向Step3 。17.4 配置项变更控制17.4.1 目的防止配置项被随意修改而导致混乱。17.4.2 角色与职责CCB 对审批变更申请。17.4.3 启动准则待变更的配置项状态为“正式发布”，或者该配置项已经成为某个基线的一部分（即被“冻结”） 。17.4.4 输入待变更的配置项17.4.5 主要步骤Step1 变更申请变更申请人向CCB 提交变更申请，重点说明“变更内容”和“变更原因”。Step2 审批变更申请CCB 审批该申请，分析此变更对项目造成的影响。如果同意变更，则转向Step3 ，否则终止本规程。补充说明：一个配置项的变更可能导致其它 配置项也发生变更，CCB 在审批变更申请时一定要考虑这些问题。Step3 安排变更任务CCB 指定变更执行人，安排他们的任务。CCB 需要和变更执行人就变更内容达成共识。补充说明：变更执行人可能是变更申请人，也可能不是。Step4 执行变更任务变更执行人根据CCB 安排的任务，修改配置项。CCB 监督变更任务的执行，如检查变更内容是否正确、是否按时完成工作等。Step5 对更改后的配置项重新进行技术评审（或审批）如果配置项是技术文档，则需要接受技术评审（参见技术评审规程SPP-PROC-TR ） 。如果配置项是“计划”这类文件，则需要项目经理（或上级领导）的审批。若配置项通过了技术评审或领导审批，则转向修改） 。Step6 ，否则转向Step4 （即重新Step6 结束变更当所有变更后的配置项都通过了技术评审或领导审批，这些配置项的状态从“正在修改”变迁为“正式发布”。 CCB 在配置项变更控制报告中签字，结束变更。17.4.6 输出本规程的所有信息都记录在配置项变更控制报告中。17.4.7 结束准则CCB 签字结束变更。17.4.8 度量CCB 统计变更工作量。17.5 实施建议要求所有人员对其工作成果进行配置管理。对全员进行配置管理培训。由于配置库里保存的是项目的所有工作成果，应当选择“责任心强、可靠”的人员担任配置管理员。选用合适的软件工具，尽量减少配置管理过程的工作量。
展开阅读全文