2022年某企业配置管理方案措施研究.docx

精选学习资料 - - - - - - - - - 第 17 章 配置治理. 2名师归纳总结 17.1 介绍 . 2第 1 页,共 12 页17.2 制定配置治理方案. 417.2.1 目的 . 417.2.2 角色与职责 . 417.2.3 启动准就 . 417.2.4 输入 . 417.2.5 主要步骤 . 4Step1 确定配置治理的软硬件资源 . 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.4 配置项版本掌握流程. 9Step1 创建配置项. 9Step2 修改处于“ 草稿” 状态的配置项. 9- - - - - - -精选学习资料 - - - - - - - - - Step3 技术评审或领导审批. 9Step4 正式发布 . 9Step5 变更 . 917.4 配置项变更掌握 . 917.4.1 目的 . 917.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 第 2 页,共 12 页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第 3 页,共 12 页的 ClearCase等；为了提高配置治理的效率和安全性,机构应当有特地的配置治理员（角- - - - - - -精选学习资料 - - - - - - - - - 色）；配置治理员为每个项目制定配置治理方案,创建和爱护配置库；鉴于配置治理的重要性和复杂性,机构仍应当设立配置掌握委员会（Configuration Control Board, CCB）； CCB 是个虚拟小组,对配置治理各项活动拥有决策权（例如审批方案,审批变更恳求等）；对于配置治理而言,CCB 是决策者,而配置治理员是执行者；假如机构的各个项目紧密相关（例如一个产品线下的多个项目）,建议机构设立公共的 CCB ,这个公共的 CCB 对全部项目的配置治理拥有决策权；假如机构的各个项目相对独立,那么每个项目可以设立各自的CCB ；CCB 的决策采纳“ 少数听从多数” 原就；配置治理的流程如图 17-1 所示；制定配置治理方案配置库治理配 置 审 计版本掌握变更掌握图 17-1 配置治理流程图一、制定配置治理方案配置治理员制定配置治理方案,主要内容包括配置治理软硬件资源、配置项方案、基线方案、交付方案、备份方案等；CCB 审批该方案；二、配置库治理配置治理员为项目创建配置库,并给每个项目成员安排权限；各项目成员依据自己的权限操作配置库；配置治理员定期爱护配置库,例如清晰垃圾文件、备份配置库等；三、版本掌握在项目开发过程中,绝大部分的配置项都要经过多次的修改才能最终确定下来；对配置项的任何修改都将产生新的版本；由于我们不能保证新版本肯定比老版本“ 好” ,所以不能抛弃老版本；版本掌握的目的是依据肯定的规章储存配置项的全部版本,防止发生版本丢失或混淆等现象,并且可以快速精确地查找到配置项的任何版本；配置项的状态有三种：“ 草稿”、“ 正式发布” 和“ 正在修改”,本规程制定了配置项状态变迁与版本号的规章；四、变更掌握在项目开发过程中,配置项发生变更几乎是不行防止的；变更掌握的目的就是为了防止配置项被随便修改而导致纷乱；修改处于“ 草稿” 状态的配置项不算是“ 变更”,无需CCB 的批准,修改者依据版本掌握规章执行即可；当配置项的状态成为“ 正式发布”,或者被 “ 冻结”后, 此时任何人都不能随便修改,必需依据“ 申请审批执行变更再评审终止” 的规章执行；名师归纳总结 - - - - - - -第 4 页,共 12 页精选学习资料 - - - - - - - - - 五、配置审计为了保证全部人员（包括项目成员、配置治理员和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 由项目经理、资深项目成员等人组成,项目经理为数” 原就；17.2.3 启动准就项目方案已经制定配置治理员和 CCB 已经确定；17.2.4 输入项目方案17.2.5 主要步骤 Step1 确定配置治理的软硬件资源CCB 负责人； CCB 的决策采纳“ 少数听从多配置治理员依据项目的规模以及财力,确定配置治理软件以及运算机资源（考虑内名师归纳总结 - - - - - - -第 5 页,共 12 页精选学习资料 - - - - - - - - - 存、外存、CPU 等）；常用的配置治理软件有Microsoft公司的Visual SourceSafe和 Rational 公司的 ClearCase 等； Step2 制定配置项方案配置治理员识别项目的主要配置项；每个配置项都有格式为Project-Type Type-Number ；唯独的 标识符,标识符的参考可以在Project（或 Product ）前面加上公司的标识符；Type Type 表示配置项类型,可以采纳多级缩写；Number 为 3 为数字,范畴从001 到 999,表示一个配置项有如干个文件；如配置项只有一个文件,就该项可以省略；配置项方案的参考格式如下：类型主要配置项标识符估量正式发布时间 Step3 制定基线方案配置治理员确定每个基线的名称（标识符）及其主要配置项,估量每个基线建立的 时间；基线方案的参考格式如下：基线名称/标识符基线所包含的主要配置项估量建立时间 Step4 制定配置库备份方案配置治理员制定配置库备份方案,指明“ 何人” 在“ 何时”“ 何处” ； Step5 审批配置治理方案（频度）将配置库备份到CCB 审批配置治理方案；如该方案被批准,就请 CCB 负责人签字认可；否就,配置治理员依据 CCB 的看法修改配置治理方案,直到该方案被批准为止；17.2.6 输出配置治理方案名师归纳总结 - - - - - - -第 6 页,共 12 页精选学习资料 - - - - - - - - - 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 创建配置库配置治理员创建配置库,并且至少创建配置库的全部第一级目录；名师归纳总结 - - - - - - -第 7 页,共 12 页精选学习资料 - - - - - - - - - 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 目的 依据肯定的规章储存配置项的全部版本,防止发生版本丢失或混淆等现象,并且可名师归纳总结 - - - - - - -第 8 页,共 12 页精选学习资料 - - - - - - - - - 以快速精确地查找到配置项的任何版本；17.3.2 角色与职责全部项目成员都必需遵照版本掌握规程操作配置库；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第 9 页,共 12 页值；参见规章（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 目的防止配置项被随便修改而导致纷乱；名师归纳总结 - - - - - - -第 10 页,共 12 页精选学习资料 - - - - - - - - - 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 ）；第 11 页,共 12 页- - - - - - -精选学习资料 - - - - - - - - - 假如配置项是“ 方案” 这类文件,就需要项目经理（或上级领导）的审批；如配置项通过了技术评审或领导审批,就转向Step6 ,否就转向Step4 （即重新修改）；Step6 终止变更当全部变更后的配置项都通过了技术评审或领导审批,这些配置项的状态从“ 正在修改” 变迁为“ 正式发布”17.4.6 输出； CCB 在配置项变更掌握报告中签字,终止变更；本规程的全部信息都记录在配置项变更掌握报告中；17.4.7 终止准就 CCB 签字终止变更；17.4.8 度量 CCB 统计变更工作量；17.5 实施建议要求全部人员对其工作成果进行配置治理；对全员进行配置治理培训；由于配置库里储存的是项目的全部工作成果,应当挑选“ 责任心强、牢靠” 的人员担任配置治理员；选用合适的软件工具,尽量削减配置治理过程的工作量；名师归纳总结 - -