徐万新之路配置管理
配置库的变更控制
配置管理六个活动
制定配置管理计划
- 配置管理计划是对如何开展项目配置管理工作的规划,是配置管理过程的基础应该形成文件并在整个项目生命周期内处于受控状态。
- 配置控制委员会(CCB)负责审批该计划。
配置项识别
配置项识别是识别所有信息系统组件的关键配置,以及各配置项间的关系和配置文档等结构识别。配置项识别是配置管理的一项基础性工作,要确定配置项的范围、属性、标识符、基准线以及配置结构和命名规则等。
配置基准线是对某个特定时点上一组配置项的描述。 一项完整的配置基准线应该包括的内容主要有: 1. 过去的、当前的和计划中的发布信息 2. 过去的、当前的和计划中的变更信息 3. 批准和实施变更时信息系统的状态和有关文档 4. 实施发布时信息系统的状态和有关文档 5. 按标准规范配置的硬件和软件
配置项控制
配置项控制即对配置项和基线的变更控制,包括:标识和记录变更申请、分析和评价变更、批准或否决申请、实现、验证和发布已修改的配置项等任务。
变更流程： 1. 变更申请 2. 变更评估 3. 通告评估结果 4. 变更实施 5. 变更验证与确认 6. 变更的发布 7. 基于配置库的变更控制
详细解释： 1. 变更申请： 2. 变更评估：CCB决定是否接受变更,并将决定通知相关人员。 3. 通告评估结果：CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。 4. 变更实施：项目经理组织修改相关的配置项,并在相应的文档、程序代码或配置管理数据中记录变更信息： 5. 变更验证与确认：项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更证的结果提交给CCB,由其确认变更是否已经按要求完成。 6. 变更的发布：配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果通知相员,并做好记录。 7. 基于配置库的变更控制：在信息系统开发项目中,一处出现了变更,经常会连锁引起多会涉及到参与开发工作的许多人员。
基于配置库的变更控制
现以某软件产品升级为例,其过程简述为: 1. 将待升级的基线(假设版本号为V2.1)从产品库中取出,放入受控库。 2. 程序员将欲修改的代码段从受控库中检出(Check out),放入自己的开发库中进行修改。代码被检出后即被”锁定“,以保证同一段代码只能同时被一个程序员修改,如果甲正对其修改,乙就无法Check out。 3. 程序员将开发库中修改好的代码段检入(Check in)受控库。检入后,代码的 “锁定”被解除 , 其他程序员可以Checkout该段代码了。 4. 软件产品的升级修改工作全部完成后,将受控库中的新基线存入产品库中(软件产品的版本号更新为V2.2,旧的V2.1版并不删除,继续在产品库中保存)。
配置审计
| 功能配置审计 | 物理配置审计 |
|---|---|
| 审计配置项的一致性 (配置项的实际功效是否与其需求一致) | 审计配置项的完整性 (配置项的物理存在是否与预期一致) |
| 具体验证主要包括: 1. 配置项的开发已圆满完成; 2. 配置项已达到配置标识中规定的性能和功能特征; 3. 配置项的操作和支持文档已完成并且是符合要求的等。 | 具体验证主要包括: 1. 要交付的配置项是否存在; 2. 配置项中是否包含了所有必需的项目等。 |
配置管理回顾与改进
配置管理回顾及改进活动包括: 1. 对本次配置管理回顾进行准备,设定日期和主题,通知相关人等参加会议。根据配置管理绩效衡量指标,要求配置项责任人提供配置项统计信息 2. 召开配置管理回顾会议,在设定日期召开回顾会议,对配置管理报告进行汇报,听取各方意见,回顾上次过程改进计划执行情况 3. 根据会议结论,制订并提交服务改进计划 4. 根据过程改进计划,协调、落实改进等
配置项
- GB/T11457《信息技术软件工程术语》对配置项的定义为:”为配置管理设计的硬件、软件或二者的集合,在配置管理过程中作为一个单个实体来对待。
- 典型配置项包括: 项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据,它们经评审和检查通过后进入配置管理。
- 在信息系统的开发流程中需加以控制的配置项可以分为基线配置项和非基线配置项两类。 基线配置项可能包括所有的设计文档和源程序等; 非基线配置项可能包括项目的各类计划和报告等。
- 配置项的操作权限应由CMO(配置管理员)严格管理,基本原则是:基线配置项向开发人放读取的权限;非基线配置项向PM、CCB及相关人员开放。
配置项状态
配置项的状态可分为”草稿””正式”和”修改”三种。 配置项刚建立时,其状态为”草稿”。 配置项通过评审后,其状态变为”正式”。 此后若更改配置项,则其状态变为”修改”。 当配置项修改完毕并重新通过评审时,其状态又变为”正式”。
配置项的版本号
- 配置项的版本号规则与配置项的状态相关
- 处于”草稿”状态的配置项的版本号格式为0.YZ,YZ的数字范围为01~99。随着草稿的修正,YZ的取值应递增。YZ的初值和增幅由用户自己把握。
- 处于”正式”状态的配置项的版本号格式为X.Y,X为主版本号,取值范围为1~9。Y为次版本号取值范围为0~9。配置项第一次成为”正式”文件时,版本号为1.0。如果配置项升级幅度比较小可以将变动部分制作成配置项的附件,附件版本依次为1.0,1.1,1,…。当附件的变动积累到一定程度时,配置项的Y值可适量增加,Y值增加一定程度时,X值将适量增加。当配置项升级幅度比较大时才允许直接增大X值。
- 处于”修改”状态的配置项的版本号格式为X.YZ。配置项顶正在修改时,一般只增大Z值,XY值不变。当配置项修改完毕,状态成为”正式”时,将Z值设置置为0,增加X.Y值
配置基线
- 配置基线由一组配置项组成,这些配置项构成一个相对稳定的逻辑实体。
- 配置基线也是指一个产品或系统在某一特定时刻的配置状况。这种配置不仅体现了其产品或系统的结构,还反映了其具体内容,从而使得以后可以按照上述配置重建该产品或系统。
- 对基线的变更必须遵循正式的变更控制程序。
- 基线通常对应于项目过程中的里程碑(Milestone),一个项目可以有多个基线,也可以只有一个基线。交付给用户使用的基线一般称为发行基线(Release),内部过程使用的基线一般称为构造基线(Build)。
配置库
针对信息系统开发类型的项目,我们常使用配置库(Configuration Library)存放配置项并记录与配置项相关的所有信息,是配置管理的有力工具。配置库可以分开发库、受控库、产品库3种类型。
| 开发库 | 受控库 | 产品库 |
|---|---|---|
| 开发库也称为动态库、程序员库或工作库,用于保存开发人员当前正在开发的配置实体,如新模块文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区,由开发人员自行控制。库中的信息可能有较为频繁的修改只要开发库的使用者认为有必要,无须对其进行配置控制,因为这通 常不会影响到项目的其他部分。 | 受控库也称为主库,包含当前的基线以及对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时,将当前的工作 产品存入受控库。 | 产品库也称为静态库、 发行库、软件仓库,包含已发布使用的各种基线的存档,被置于完全的配置管理之下。在开发的信息系统产品完成 系统测试之后,作为最终产品存入产品库内,等待交付用户或现场安 装。 |
配置管理角色
变更控制委员会(Change Control Board,CCB)、配置管理负责人、记置管理员和配置项负责人等。 1. 配置管理负责人: 配置管理负责人也称配置经理,负责管理和决策整个项目生命周期中的配置活动,具体有: 1. 管理所有活动,包括计划、识别、控制、审计和回顾; 2. 负责配置管理过程; 3. 通过审计过程确保配置管理数据库的准确和真实; 4. 审批配置库或配置管理数据库的结构性变更; 5. 定义配置项责任人; 6. 指派配置审计员; 7. 定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态; 8. 评估配置管理过程并持续改进; 9. 参与变更管理过程评估; 10. 对项目成员进行配置管理培训。 2. 配置管理员：配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动,具体有: 1. 建立和维护配置管理系统; 2. 建立和维护配置库或配置管理数据库; 3. 配置项识别; 4. 建立和管理基线; 5. 版本管理和配置控制; 6. 配置状态报告; 7. 配置审计; 8. 发布管理和交付。 3. 配置项负责人：配置项负责人确保所负责的配置项的准确和真实: 1. 记录所负责配置项的所有变更; 2. 维护配置项之间的关系; 3. 调查审计中发现的配置项差异,完成差异报告; 4. 遵从配置管理过程; 5. 参与配置管理过程评估。
配置管理关键成功因素
配置管理关键成功因素主要包括: 1. 所有配置项应该记录; 2. 配置项应该分类; 3. 所有配置项要编号; 4. 应该定期对配置库或配置管理数据库中的配置项信息进行审计; 5. 每个配置项在建立后,应有配置负责人负责; 6. 要关注配置项的变化情况; 7. 应该定期对配置管理进行回顾; 8. 能够与项目的其他管理活动进行关联。
变更管理
变更的分类
根据变更性质分为: 重大变更、重要变更和一般变更。通过不同审批权限控制。
根据变更迫切性分为: 紧急变更、非紧急变更。通过不同变更处理流程进行。
根据行业特点分类: 如弱电工程行业的常见分类方法为产品(工作)范围变更、环境变更、设计变更、实施变更和技术标准变更。
角色和职责—-项目经理
项目经理是组织委托的项目经营过程负责者,其正式权利由项目章程取得,而资源调度的权力通常由基准中明确,在变更中的作用: 1. 响应变更提出者的需求 2. 评估变更对项目的影响及应对方案 3. 将需求由技术要求转化为资源需求,供授权人决策 4. 根据评审结果实施即调整基准,确保项目基准反映项目实际情况
角色和职责—变更管理负责人
变更管理负责人也称变更经理,通常是变更管理过程解决方案的负责人,其主要职责包括: 1. 负责整个变更过程方案的结果; 2. 负责变更管理过程的监控; 3. 负责协调相关的资源,保障所有变更按照预定过程顺利运作; 4. 确定变更类型,组织变更计划和日程安排; 5. 管理变更的日程安排; 6. 变更实施完成之后的回顾和关闭; 7. 承担变更相关责任,并且具有相应权限; 8. 可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。
角色和职责—变更请求者、变更实施者、变更顾问委员会
变更请求者负责记录与提交变更请求单,具体为: 1. 提交初步的变更方案和计划; 2. 初评价变更的风险和影响,给变更请求设定适当的变更类型; 3. 对理解变更过程有能力要求等。
变更实施者需要拥有执行变更方案的内容的技术能力,负责按照实施计划实施具体的变更任务。
变更顾问委员会负责对重大变更行使审批,提供专业意见和辅助审批,具体为: 1. 在紧急变更时,其中被授权者行使审批权限; 2. 定期听取变更经理汇报,评估变更管理执行情况,必要时提出改进建议等。
变更管理工作程序
- 变更申请
- 对变更初审
- 变更方案论证
- 变更审查
- 发出通知并实施
- 实施监控
- 效果评估
- 变更收尾
变更申请
般项目经理或配置管理员负责变更相关信息的收集以及对变更申请的初审
变更初审
对变更初审:文档审核流转 1. 对变更提出方施加影响,确认变更的必要性 2. 格式校验、完整性校验 3. 在干系人间就提出供评估的变更信息达成共识
变更方案论证
由技术要求转化为资源需求,可召开专家论证会,通常需要由变更顾问委员会(相关技术和经济方面的专家组成)进行相关论证,并供CCB决策
变更审查
变更审查过程是项目所有者根据变更申请及评估方案,决定是否变更项目基准。审查通常采用文档、会签形式,重大的变更审查可以采用正式会议形式。
发出通知并实施
变更通知不只是包括项目实施基准的调整,更要明确项目的交付日期、成果对相关干系人的影响。如果变更造成交付期调整,应在变更确认时发布,而非在交付前公布。
实施监控
- 项目经理负责基准的监控;
- CCB监控变更的主要成果、进度里程碑。
效果评估
- 评估依据是项目的基准;
- 结合变更的目标,评估变更所要达到的目的是否已达成;
- 评估变更方案中的技术论证、经济论证内容与实施过程的为差距,并促使解决。
变更收尾
判断发生变更后，项目是否纳入正常轨道
项目文档管理
信息系统开发项目的文档一般分为三类:开发文档、产品文档、管理文档。
| 类别 | 功能 | 示例 |
|---|---|---|
| 开发文档 | 描述开发过程本身 | 可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明(包括程序和数据规格说明、开发计划、软件集成和测试计划、质量保证计划、安全和测试信息等)。 |
| 产品文档 | 描述开发过程的产物 | 培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告。 |
| 管理文档 | 记录项目管理的信息 | 开发过程的每个阶段的进度和进度变更的记录;软件变更情况的记录;开发团队的职责定义、项目计划、项目阶段报告、配置管理计划。 |
文档的质量分级
- 最低限度文档(1级文档),适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。
- 内部文档(2级文档),可用于没有与其他用户共享资源的专用程序。除1级文档提供的信息外,2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
- 工作文档(3级文档),适合于由同一单位内若干人联合开发的程序,或可被其他单位使用的程序。
- 正式文档(4级文档),适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质(如工资计算)的程序需要4级文档。4级文档守GB/T2006-8567的有关规定。
规则和方法
文档的规范化管理主要体现在文档书写规范(遵循统一的书写规范)、图表编号规则(方便查找, 采用分类结构)、文档目录编写标准(方便使用,采用分类结构)和文档管理制度(更好管理,权限分配、保密制度)等几个方面。
图标编号规则： 1. 第1位：生命周期法各阶段 2. 第2位：各阶段的文档 3. 第3、4位：文档内容 4. 第5、6位：流水码
