软考高项（十九）配置与变更管理 ★重点集萃★

👑 个人主页 👑 ：😜😜😜Fish_Vast😜😜😜
🐝 个人格言 🐝 ：🧐🧐🧐说到做到，言出必行🧐🧐🧐
🐸 推荐专栏 🐸 ：SpringBoot
🐸 推荐专栏 🐸 ：Java基础
🐸 推荐专栏 🐸 ：软考
🍉 博客描述 🍉 ：行好每一次程，写好每一篇文！
🍀 本篇简介 🍀 ：分享软考高项核心考点之配置与变更管理内容。

1、配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。

2、所有配置项都应按照相关规定统一编号，并以一定的目录结构保存在CMDB（配置管理数据库）中。配置项可以分为基线配置项和非基线配置项两类，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应有配置管理员严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项项目经理、CCB（变更控制委员会）及相关人员开放。

3、可将配置项状态分为“草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。配置项状态变化如下图所示。

4、配置项版本号
① 处于“草稿”状态的配置项的版本号格式为0.YZ，随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。
② 处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，Y为次版本号。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0,1.1；…当附件的变动积累到一定程度时，配置项的Y值可适量增加。Y值增加到一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值。
③ 处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为正式时，将Z值设置为0，增加X.Y值。

5、在信息系统开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

6、配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。配置基线也是指一个产品或系统在某一特定时刻的配置状况。

7、基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。例如，一组拥有唯一标识号的需求、设计、源代码文档以及相应的可执行代码、构造文档和用户文档构成一条基线。产品的一个测试版本也是基线的例子。

8、基线通常对应于项目过程中的里程牌，一个项目可以有多个基线，也可以只有一个基线。交付给用户使用的基线一般称为发行基线，内部过程使用的基线一般称为构造基线。

9、我们常使用配置库管理数据库来管理配置项，它是指包含每个配置项及配置项之间重要关系的详细资料的数据库。

10、配置库可以分开发库、受控库、产品库3种类型。
（1）开发库，也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如：新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。可以任意的修改。
（2）受控库，也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。可以修改，需要走变更流程。
（3）产品库，也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。一般不再修改，真要修改的话需要走变更流程。

11、配置库的建库模式有两种：按配置项类型建库和按开发任务建库。
（1）按配置项的类型分类建库。这种模式适用于通用软件的开发组织。在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。
（2）按开发任务建立相应的配置库。这种模式适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以没必要把配置项严格分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。

12、配置管理负责人也称配置经理，负责管理和决策整个项目生命周期中的配置活动。具体有：
① 管理所有活动，包括计划、识别、控制、审计和回顾
② 负责配置管理过程
③ 通过审计过程确保配置管理数据库的准确和真实
④ 审批配置库或配置管理数据库的结构性变更
⑤ 定义配置项责任人
⑥ 指派配置审计员
⑦ 定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态
⑧ 评估配置管理过程并持续改进
⑨ 参与变更管理过程评估
⑩ 对项目成员进行配置管理培训

13、配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动，具体有：
① 建立和维护配置管理系统
② 建立和维护配置库或配置管理数据库
③ 配置项识别
④ 建立和管理基线
⑤ 版本管理和配置控制
⑥ 配置状态报告
⑦ 配置审计
⑧ 发布管理和交付

14、配置项负责人确保所负责的配置项的准确和真实：
① 记录所负责配置项的所有变更
② 维护配置项之间的关系
③ 调查审计中发现的配置项差异，完成差异报告
④ 遵从配置管理过程
⑤ 参与配置管理过程评估

15、配置管理的日常管理活动主要包括：制订配置管理计划、配置项识别、配置项控制、配置状态报告、配置审计、配置管理回顾与改进等。

16、配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。CCB负责审批该计划。

17、配置项识别是识别所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构识别。它包括为配置项分配标识和版本号等。配置项识别是配置管理的一项基础性工作，要确定配置项的范围、属性、标识符、基准线以及配置结构和命名规则等。

18、配置项控制即对配置项和基线的变更控制，包括：标识和记录变更申请、分析和评价变更、批准或否决申请、实现、验证和发布已修改的配置项等任务。
（1）变更申请。
（2）变更评估。CCB负责组织对变更申请进行评估并确定：
① 变更对项目的影响
② 变更的内容是否必要
③ 变更的范围是否考虑周全
④ 变更的实施方案是否可行
⑤ 变更工作量估计是否合理
CCB决定是否接受变更，并将决定通知相关人员。
（3）通告评估结果。CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。如果变更申请得到批准，应该及时把变更批准信息和变更实施方案通知给那些正在使用受影响的配置项和基线的干系人。如果变更申请被否决，应通知有关干系人放弃该变更申请。
（4）变更实施。项目经理组织修改相关的配置项，并在相应的文档、程序代码或配置管理数据中记录变更信息。
（5）变更验证与确认。项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交给CCB，由其确认变更是否已经按要求完成。
（6）变更的发布。配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果通知相关人员，并做好记录。

19、基于配置库的变更控制。如下图所示。

以某软件产品升级为例，其过程简述为：
（1）将待升级的基线（假设版本号为V2.1）从产品库中取出，放入受控库。
（2）程序员将欲修改的代码段从受控库中检出（Check out），放入自己的开发库中进行修改。代码被检出后即被“锁定”以保证同一段代码只能同时被1个程序员修改。如果甲正对其修改，乙就无法Check out。
（3）程序员将开发库中修改好的代码段检入（Check in）受控库。检入后，代码的“锁定”被解除，其他程序员可以Check out该段代码了。
（4）软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品的版本号更新为V2.2，旧的V2.1版并不删除，继续在产品库中保存）

20、配置状态报告也称配置状态统计，其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。

21、配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求，不允许出现任何混乱现象。
1）功能配置审计。功能配置审计是审计配置项的一致性（配置项的实际功效是否与其需求一致），具体验证：
（1）配置项的开发已圆满完成
（2）配置项已达到配置标识中规定的性能和功能特征
（3）配置项的操作和支持文档已完成并且是符合要求的等
2）物理配置审计。物理配置审计是审计配置项的完整性（配置项的物理存在是否与预期一致），具体验证：
（1）要交付的配置项是否存在
（2）配置项中是否包含了所有必需的项目

22、配置管理回顾与改进即定期回顾配置管理活动的实施情况，发现在配置管理执行过程中有无问题，找到改进点，继而优化配置管理过程。配置管理回顾及改进活动包括：
① 对本次配置管理回顾进行准备，设定日期和主题通知相关人等参加会议
② 召开配置管理回顾会议
③ 根据会议结论，制订并提交服务改进计划
④ 根据过程改进计划，协调、落实改进等

23、变更的常见原因包括：
① 产品范围（成果）定义的过失或者疏忽
② 项目范围（工作）定义的过失或者疏忽
③ 增值变更
④ 应对风险的紧急计划或回避计划
⑤ 项目执行过程与基准要求不一致带来的被动调整
⑥ 外部事件等

24、根据变更性质可分为重大变更、重要变更和一般变更，通过不同审批权限进行控制。根据变更的迫切性可分为紧急变更、非紧急变更。

25、变更管理是为使得项目基准与项目实际执行情况相一致，应对项目变化的一套管理方法。其可能得两个结果是拒绝变化，或是调整项目基准。

26、变更管理的原则是项目基准化和变更管理过程规范化。主要内容包括：
（1）基准管理：基准是变更的依据。每次变更通过评审后，都应重新确定基准。
（2）变更控制流程化：建立或选用符合项目需要的变更管理流程，所有变更都必须遵循这个控制流程。
（3）明确组织分工：至少应明确变更相关工作的评估、评审、执行的职能。
（4）评估变更的可能影响。
（5）妥善保存变更产生的相关文档：适当时可以引入配置管理工具。

27、项目经理在变更中的作用是：响应变更提出者的需求：评估变更对项目的影响及应对方案；将需求由技术要求转化为资源需求，供授权人决策；并据评审结果实施（即调整基准），确保项目基准反映项目实施情况。

28、变更管理负责人也称变更经理，通常是变更管理过程解决方案的负责人，其主要职责包括：
（1）负责整个变更过程方案的结果
（2）负责变更管理过程的监控
（3）负责协调相关的资源，保障所有变更按照预定过程顺利运作
（4）确定变更类型，组织变更计划和日程安排
（5）管理变更的日程安排
（6）变更实施完成之后的回顾和关闭
（7）承担变更相关责任，并且具有相应权限
（8）可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等

29、变更请求者负责记录与提交变更请求单，具体为：
（1）提交初步的变更方案和计划
（2）初步评价变更的风险和影响，给变更请求设定适当的变更类型
（3）对理解变更过程有能力要求等

30、变更实施者需要拥有有执行变更方案的内容的技术能力，负责按照实施计划实施具体的变更任务。

31、变更顾问委员会负责对重大变更行使审批，提供专业意见和辅助审批，具体为：
（1）在紧急变更时，其中被授权者行使审批权限
（2）定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等

32、工作程序
（1）变更申请：变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但在评估前应以书面形式提出。项目的干系人都可以提出变更申请，但一般情况下都需要经过指定人员进行审批，一般项目经理或者项目配置管理员负责该相关信息的收集，以及对变更申请的初审。
（2）对变更的初审：变更初审的目的主要包括：
① 对变更提出方施加影响，确认变更的必要性，确保变更是有价值的
② 格式校验，完整性校验，确保评估所需信息准备充分
③ 在干系人间就提出供评估的变更信息达成共识等
变更初审的常见方式为变更申请文档的审核流转
（3）变更方案论证：变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求，以供CCB决策。对于一些大型的变更，可以召开相关的变更方案论证会议，通常需要由变更顾问委员会（相关技术和经济方面的专家组成）进行相关论证，并将相关专家意见作为项目变更方案的一部分，报项目CCB作为决策参考。
（4）变更审查：变更审查过程是项目所有者根据变更申请及评估方案，决定是否变更项目基准。
（5）发出通知并实施
（6）实施监控：变更实施的过程监控，通常由项目经理负责基准的监控。CCB监控变更明确的主要成果、进度里程碑等，也可以通过监理单位完成监控。
（7）效果评估：变更评估的关注内容主要包括：
① 评估依据是项目的基准
② 结合变更的目标，评估变更所要达到的目的是否已达成
③ 评估变更方案中的技术论证、经济论证内容与实施过程的差距，并促使解决。
（8）变更收尾：变更收尾是判断发生变更后的项目是否已纳入正常轨道。

33、在项目整体压力较大的情况下，更需强调变更的提出和处理应当规范化，可以使用分批处理、分优先级等方式提高效率。项目规模小、与其他项目的关联度小时，变更的提出与处理过程可在操作上力求简便、高效。但小项目的变更仍应注意对变更产生的因素施加影响（如防止不必要的变更，减少无畏的评估，提高必要变更的通过效率等），对变更的确认应当正式化，变更的操作过程应当规范化等。

34、为确保版本发布的成功，在版本发布前应对每次版本发布进行管理，并做好发布失败后的回退方案。

35、对于信息系统开发项目来说，其文档一般分开发文档、产品文档和管理文档。
（1）开发文档描述开发过程本身，基本的开发文档包括：可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明。
（2）产品文档描述开发过程的产物，基本的产品文档包括：培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告。
（3）管理文档记录项目管理的信息，例如：开发过程的每个阶段进度和进度变更的记录：软件变更情况的记录：开发团队的职责定义、项目计划、项目阶段报告；配置管理计划。

36、文档的质量通常可以分为4级：
（1）最低限度文档（1级文档）：适合开发工作量低于一个人月的开发者自用程序。
（2）内部文档（2级文档）：可用于没有与其他用户共享资源的专用程序。
（3）工作文档（3级文档）：适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。
（4）正式文档（4级文档）：适合那些要正式发行供普遍使用的软件产品。

37、文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。
（1）文档书写规范。管理信息系统的文档资料涉及文本、图形和表格等多种类型，无论是哪种类型的文档都应该遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等。
（2）图表编号规则。在管理信息系统的开发过程中用到很多的图表，对这些图表进行有规则地编号，可以方便图表的查找。
（3）文档目录编写标准。为了存档及未来使用的方便，应该编写文档目录。管理信息系统的文档目录中应包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等。
（4）文档管理制度。文档的管理制度需要根据组织实体的具体情况而定，主要包括建立文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则等。