软考高项总结：第19章配置与变更管理

一、配置管理

1、配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。

2、配置项是信息系统组件或与其有关的项目，包括软件、硬件和各种文档，如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等。

3、典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等

4、配置项可以分为基线配置项和非基线配置项两类：

5、配置项的状态可分为“草稿”“正式”和“修改”三种。

（1）配置项刚建立时，其状态为“草稿”【0.YZ】

（2）配置项通过评审后，其状态变为“正式”【X.Y】

（3）若更改配置项，则其状态变为“修改”【X.YZ】

（4）当配置项修改完毕并重新通过评审时，其状态又变为“正式”

6、配置项的版本号

（1）处于“草稿”状态的配置项的版本号格式为0.YZ，YZ的数字范围为01～99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。(例如∶0.1、0.5、0.99 )

（2）处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1～9。Y为次版本号，取值范围为0～9。配置项第一次成为“正式”文件时，版本号为1.0。(例如∶1.1、1.5、2.3 )

（3）处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。 (例如∶1.15、1.16 )

7、配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

8、配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改，对基线的变更必须遵循正式的变更控制程序。

9、产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、己编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子。

10、基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线，内部开发使用的基线一般称为构造基线。

11、对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。

12、配置管理数据库主要内容包括：

①发布内容，包括每个配置项及其版本号；

②经批准的变更可能影响到的配置项；

③与某个配置项有关的所有变更请求；

④配置项变更轨迹；

⑤特定的设备和软件；

⑥计划升级、替换或弃用的配置项；

⑦与配置项有关的变更和问题；

⑧来自于特定时期特定供应商的配置项；

⑨受问题影响的所有配置项。

13、配置库可以分开发库、受控库、产品库3种：

14、配置库的建库模式有两种：按配置项类型建库和按任务建库

15、配置管理相关角色常包括：变更控制委员会(CCB)、配置管理负责人、配置管理员和配置项负责人等。

16、配置管理负责人也称配置经理，负责管理和决策整个项目生命周期中的配置活动，具体有：

①管理所有活动，包括计划、识别、控制、审计和回顾；

②负责配置管理过程；

③通过审计过程确保配置管理数据库的准确和真实；

④审批配置库或配置管理数据库的结构性变更；

⑤定义配置项责任人；

⑥指派配置审计员；

⑦定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态；

⑧评估配置管理过程并持续改进；

⑨参与变更管理过程评估；

⑩对项目成员进行配置管理培训。

17、配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动，具体有：

①建立和维护配置管理系统；

②建立和维护配置库或配置管理数据库；

③配置项识别；

④建立和管理基线；

⑤版本管理和配置控制；

⑥配置状态报告；

⑦配置审计；

⑧发布管理和交付。

18、配置项负责人确保所负责的配置项的准确和真实：

①记录所负责配置项的所有变更；

②维护配置项之间的关系；

③调查审计中发现的配置项差异，完成差异报告；

④遵从配置管理过程；

⑤参与配置管理过程评估。

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

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

21、配置管理计划的主要内容为:

（1）配置管理的目标和范围。

（2）配置管理活动主要包括配置项标识、配置项控制、配置状态报告、配置审计、发布管理与交付等。

（3）配置管理角色和责任安排。

（4）实施这些活动的规范和流程，如配置项命名规则。实施这些活动的进度安排，如日程安排和程序。与其他管理之间（如变更管理等）的接口控制。

（5）负责实施这些活动的人员或团队，以及他们和其他团队之间的关系。

（6）配置管理信息系统的规划，包括配置数据的存放地点、配置项运行的受控环境、与其他服务管理系统的联系和接口、构建和安装支持工具等。

（7）配置管理的日常事务，包括许可证控制、配置项的存档等。

（8）计划的配置基准线、重大发布、里程碑，以及针对以后每个期间的工作量计划和资源计划。

22、配置项识别要确定配置项的范围、属性、标识符、基准线以及配置结构和命名规则等。

23、配置项控制即对配置项和基线的变更控制，包括：标识和记录变更申请、分析和评价变更、批准或否决申请、实现、验证和发布已修改的配置项等任务。

24、配置状态报告应该包含以下内容：

①每个受控配置项的标识和状态；

②每个变更申请的状态和已批准的修改的实施状态；

③每个基线的当前和过去版本的状态以及各版本的比较；

④其他配置管理过程活动的记录；

25、配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。

26、配置审计的实施是为了确保项目配置管理的有效性，不允许出现任何混乱现象，作用：

①防止向用户提交不适合的产品，如交付了用户手册的不正确版本。

②发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。

③找出各配置项间不匹配或不相容的现象。

④确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。

⑤确认记录和文档保持着可追溯性。

27、功能配置审计是审计配置项的一致性（配置项的实际功效是否与其需求一致），验证：

①配置项的开发已圆满完成；

②配置项已达到配置标识中规定的性能和功能特征；

③配置项的操作和支持文档己完成并且是符合要求的。

28、物理配置审计是审计配置项的完整性（配置项的物理存在是否与预期一致），验证：

①要交付的配置项是否存在；

②配置项中是否包含了所有必需的项目；

29、应当进行配置审计的场景包括：

①实施新的配置库或配置管理数据库之后；

②对信息系统实施重大变更前后；

③在一项软件发布和安装被导入实际运作环境之前；

④灾难恢复之后或事件恢复正常之后；

⑤发现未经授权的配置项后；

⑥任何其他必要的时候等；

30、配置管理回顾及改进活动包括：

①对本次配置管理回顾进行准备，设定日期和主题，通知相关人等参加会议。根据配置管理绩效衡量指标，要求配置项责任人提供配置项统计信息；

②召开配置管理回顾会议，在设定日期召开回顾会议，对配置管理报告进行汇报，听取各方意见，回顾上次过程改进计划执行情况；

③根据会议结论，制订并提交服务改进计划；

④根据过程改进计划，协调、落实改进等；

二、变更管理

1、变更管理的实质，是根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求，提升项目价值。

2、变更的常见原因：

①产品范围（成果）定义的过失或者疏忽。

②项目范围（工作）定义的过失或者疏忽。

③增值变更。

④应对风险的紧急计划或回避计划。

⑤项目执行过程与基准要求不一致带来的被动调整。

⑥外部事件。

3、变更分类

（1）根据变更性质可分为：重大变更、重要变更和一般变更，通过不同审批权限控制。

（2）根据变更的迫切性可分为：紧急变更、非紧急变更。通过不同变更处理流程进行。

4、变更管理，即是为使得项目基准与项目实际执行情况相一致，应对项目变化的一套管理方法。

5、变更管理的原则是项目基准化、变更管理过程规范化。包括：

①基准管理

②变更控制流程化

③明确组织分工

④评估变更的可能影响

⑤妥善保存变更产生的相关文档

（1）基准管理：基准是变更的依据。在项目实施过程中，基准计划确定并经过评审后（通常用户应参与部分评审工作），建立初始基准。此后每次变更通过评审后，都应重新确定基准。

（2）变更控制流程化：所有变更都必须遵循这个控制流程进行控制。

（3）明确组织分工：至少应明确变更相关工作的评估、评审、执行的职能。

（4）评估变更的可能影响：变更的来源是多样的，既需要完成对客户可视的成果、交付期等变更操作，还需要完成对客户不可视的项目内部工作的变更。

（5）妥善保存变更产生的相关文档，确保其完整、及时、准确、清晰，适当时可以引入配置管理工具。

6、信息系统项目中，除项目经理和CCB外，通常还会定义变更管理负责人、变更请求者、变更实施者和变更顾问委员会等。

7、变更的流程：①变更申请 → ②对变更的初审 → ③变更方案论证 → ④变更审查 → ⑤发出通知并实施 → ⑥实施监控 → ⑦效果评估 → ⑧变更收尾

8、项目规模小、与其他项目的关联度小时，变更的提出与处理过程可在操作上力求简便、高效。但小项目的变更仍应注意对变更产生的因素施加影响（如防止不必要的变更，减少无谓的评估，提高必要变更的通过效率等)，对变更的确认应当正式化，变更的操作过程应当规范化。

9、变更申请的提交，首先应当确保覆盖所有变更操作，这意味着如果变更申请操作可以被绕过，那么变更申请的严格管理便毫无意义；但项目应根据变更的影响和代价提高变更流程的效率，并在某些情况下使用进度管理中的快速跟进等方法。

10、回退步骤通常包括：

①通知相关用户系统开始回退；

②通知各关联系统进行版本回退；

③回退存储过程等数据对象；

④配置数据回退；

⑤应用程序、接口程序、工作流等版本回退；

⑥回退完成通知各周边关联系统；

⑦回退后进行相关测试，保证回退系统能够正常运行；

⑧通知用户回退完成等。

三、项目文档管理

1、软件文档分为三类：开发文档、产品文档、管理文档

2、文档的质量可以分为四级

3、文档的规范化管理主要体现在：①文档书写规范；②图表编号规则；③文档目录编写标准；④文档管理制度等几个方面。