配置与变更管理(3分选择题，1个小结1分)

配置管理

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

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

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

4.配置项可以分为基线配置项和非基线配置项两类 CMO配置员管理所有配置，基限配置项开发人员读取，非基线配置项项PM,CCB以及相关人员开放

5、配置项的状态可分为“草稿”“正式”和“修改”三种。 ◆ 配置项刚建立时，其状态为“草稿”【0.YZ】 ◆ 配置项通过评审后，其状态变为“正式”【X.Y】 ◆ 若更改配置项，则其状态变为“修改”【X.YZ】 ◆ 当配置项修改完毕并重新通过评审时，其状态又变为“正式”

6、配置项的版本号 ①处于“草稿”状态的配置项的版本号格式为0.YZ，YZ的数字范围为01～99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。(例如∶0.1、0.5、0.99 ) ②处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1～9。Y为次版本号，取值范围为0～9。配置项第一次成为“正式”文件时，版本号为1.0。(例如∶1.1、1.5、2.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)、配置管理负责人、配置管理员和配置项负责人等。 CCB叫法一样，但是配置包含变更，人员组成可能一致。

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

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

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

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

20、配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。CCB负责审批该计划。 CMO配置管理员制定配置管理计划，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、文档的规范化管理主要体现在： ①文档书写规范； ②图表编号规则； ③文档目录编写标准； ④文档管理制度等几个方面。

相关练习

【例1-17上】以下关于软件版本控制的叙述中，正确的是（B）。 A.软件开发人员对源文件的修改在配置库中进行(开发库) B.受控库用于管理当前基线和控制基线的变更 C.版本管理与发布由CCB执行(CCB决策并不执行) D.软件版本升级后，新基线存入产品库且版本号更新，旧版本可删除（不能删）

【例2-18上】某软件开发项目在测试时发现需求需要调整，涉及到需求规格说明书、概要设计、详细设计及代码等相关文档的变更，需要对（B）进行变更控制。 A.知识库 B.配置库 C.产品库 D.数据库

【例3-18下】关于软件配置管理的描述，不正确的是（A）。 A.配置控制委员会成员必须是专职人员(不一定) B.配置库包括动态库（开发库）、受控库（主库）、静态库（产品库） C.常用的配置管理工具有AVN、GIT等 D.配置项的状态分为草稿、正式和修改三种

【例4-18下】在项目配置项与基线的变更控制中，（D）是配置管理员们主要工作。 A.确定受变更影响的关联配置项和有关基线(相关人员，比如产品经理) B.将变更申请的决议通知受此变更影响的每个干系人(产品经理) C.组织修改配置项，并在相应的文档或程序代码中记录变更信息(产品经理) D.将变更后的配置项纳入基线，并将变更内容和结果通知相关人

【例5-19上】配置管理工作中，确定配置项的所有者及其责任、确定配置项进入配置管理的时间和条件是（D）的工作内容。 A.配置状态报告 B.配置审计 C.配置控制 D.配置标识

【例6-19上】关于配置控制委员会（CCB）的说法，正确的是（D）。 A.CCB负责分配配置库的操作权限(CMO) B.CCB负责制定配置管理计划(CMO) C.CCB必须是常设机构(也可以是临时机构) D.CCB可以是兼职人员

【例7-20下】关于配置管理的描述,正确的是（D）。 A.某个配置项的版本号为0.91,该配置项的状态为“正式”(草稿) B.配置版本管理的目的是保留配置项的最新版本,删除所有旧的版本,以避免发生版本混淆(不能删) C.一个产品只能有一个基线,因此对基线的变更必须遵循正式的变更控制程序(多个基线) D.开发库中的信息可能被频繁修改,因此可以由开发人员自行控制

【例8-20下】配置管理员的工作职责不包括（A）。 A.基线设立审批(CCB做) B.版本管理和配置控制 C.建立和维护配置库 D.配置状态报告

【例9-21上】某软件产品集成测试阶段，发现问题需要对源代码进行修改，此时，程序员将待修改的代码段从（）检出，放入自己的（）中进行修改，代码即被质定保证同一段代码只能被一个程序员修改。(B) A.产品库、开发库 B.受控库、开发库 C.产品库、受控库 D.受控库、产品库

【例10-21下】A、B两个开发人员对信息系统的同一软件部件的两个bug（位于同一代码段）进行修改，当B欲把计划修改的代码段从（）检出时，显示锁定，基于配置库的变更控制，可知此时该代码段正在工程师A的（）中进行修改。(B) A.开发库、受控库 B.受控库、开发库 C.受控库、产品库 D.产品库、开发库

【例11-22上】在配置控制中，（D）不属于CCB变更。 A.变更实施方案可行性 B.变更工作量的合理性 C.变更对项目的影响 D.记录变更信息的准确性（初审做，项目经理做）

【例12-22下】属于物理配置审计活动的（C）。 A.验证配置项已达到配置标识中的性能和功能特征 B.验证配置项的开发已圆满完成 C.验证要交付的配置项是否存在(物理配置有没有，全不全) D.验证配置项的操作和支持文档已完成并且是符合要求的

【例13-22下】在采用基于配置库的变更控制对软件代码进行修改过程中，请将下列活动按照时间先后顺序排列（C）。 ①将新基线存入产品库 ②从产品库中取出待修改代码 ③程序员在开发库中修改代码 ④将待修改代码从受控库中检出 A.①②③④ B.②①④③ C.②④③① D.③①②④

【例14-23上】在配置审计的工作中，（A）不属于功能配置审计验证的内容。 A.要交付的配置项是否存在（物理） B.配置项的开发已圆满完成 C.配置项已达到配置标识中规定的性能和功能特征 D.配置项的操作和支持文档已完成并且是符合要求的

【例15-23上】关于项目变更管理的描述，不正确的是（A）。 A.项目范围（工作）和产品范围（工作）定义的过失或者疏忽不属于变更的原因(属于) B.项目规模小、与其他项目的关联度越小时，变更的提出和处理过程可在操作上力求简便、高效 C.变更管理的实质是根据项目情况不断调整项目方向和资源配置，最大程度满足项目需求 D.在项目变更过程控制中，需要对进度变更控制、成本变更控制和合同变更控制等进行重点关注

【例16-23上】文档的规范化管理主要体现在（D）方面。 ①文档书写规范②文档质量级别(不是)③图表编号规则 ④文档目录编写标准⑤文档管理制度⑥文档安全标准(不是) A.①②③④ B.②③④⑤ C.③④⑤⑥ D.①③④⑤

刷题纯享

【例1-17上】以下关于软件版本控制的叙述中，正确的是（）。 A.软件开发人员对源文件的修改在配置库中进行 B.受控库用于管理当前基线和控制基线的变更 C.版本管理与发布由CCB执行 D.软件版本升级后，新基线存入产品库且版本号更新，旧版本可删除

【例2-18上】某软件开发项目在测试时发现需求需要调整，涉及到需求规格说明书、概要设计、详细设计及代码等相关文档的变更，需要对（）进行变更控制。 A.知识库 B.配置库 C.产品库 D.数据库

【例3-18下】关于软件配置管理的描述，不正确的是（）。 A.配置控制委员会成员必须是专职人员 B.配置库包括动态库（开发库）、受控库（主库）、静态库（产品库） C.常用的配置管理工具有AVN、GIT等 D.配置项的状态分为草稿、正式和修改三种

【例4-18下】在项目配置项与基线的变更控制中，（）是配置管理员们主要工作。 A.确定受变更影响的关联配置项和有关基线 B.将变更申请的决议通知受此变更影响的每个干系人 C.组织修改配置项，并在相应的文档或程序代码中记录变更信息 D.将变更后的配置项纳入基线，并将变更内容和结果通知相关人

【例5-19上】配置管理工作中，确定配置项的所有者及其责任、确定配置项进入配置管理的时间和条件是（）的工作内容。 A.配置状态报告 B.配置审计 C.配置控制 D.配置标识

【例6-19上】关于配置控制委员会（CCB）的说法，正确的是（）。 A.CCB负责分配配置库的操作权限 B.CCB负责制定配置管理计划 C.CCB必须是常设机构 D.CCB可以是兼职人员

【例7-20下】关于配置管理的描述,正确的是（）。 A.某个配置项的版本号为0.91,该配置项的状态为“正式” B.配置版本管理的目的是保留配置项的最新版本,删除所有旧的版本,以避免发生版本混淆 C.一个产品只能有一个基线,因此对基线的变更必须遵循正式的变更控制程序 D.开发库中的信息可能被频繁修改,因此可以由开发人员自行控制

【例8-20下】配置管理员的工作职责不包括（）。 A.基线设立审批 B.版本管理和配置控制 C.建立和维护配置库 D.配置状态报告

【例9-21上】某软件产品集成测试阶段，发现问题需要对源代码进行修改，此时，程序员将待修改的代码段从（）检出，放入自己的（）中进行修改，代码即被质定保证同一段代码只能被一个程序员修改。 A.产品库、开发库 B.受控库、开发库 C.产品库、受控库 D.受控库、产品库

【例10-21下】A、B两个开发人员对信息系统的同一软件部件的两个bug（位于同一代码段）进行修改，当B欲把计划修改的代码段从（）检出时，显示锁定，基于配置库的变更控制，可知此时该代码段正在工程师A的（）中进行修改。 A.开发库、受控库 B.受控库、开发库 C.受控库、产品库 D.产品库、开发库

【例11-22上】在配置控制中，（）不属于CCB变更。 A.变更实施方案可行性 B.变更工作量的合理性 C.变更对项目的影响 D.记录变更信息的准确性

【例12-22下】属于物理配置审计活动的（）。 A.验证配置项已达到配置标识中的性能和功能特征 B.验证配置项的开发已圆满完成 C.验证要交付的配置项是否存在 D.验证配置项的操作和支持文档已完成并且是符合要求的

【例13-22下】在采用基于配置库的变更控制对软件代码进行修改过程中，请将下列活动按照时间先后顺序排列（）。 ①将新基线存入产品库 ②从产品库中取出待修改代码 ③程序员在开发库中修改代码 ④将待修改代码从受控库中检出 A.①②③④ B.②①④③ C.②④③① D.③①②④

【例14-23上】在配置审计的工作中，（）不属于功能配置审计验证的内容。 A.要交付的配置项是否存在 B.配置项的开发已圆满完成 C.配置项已达到配置标识中规定的性能和功能特征 D.配置项的操作和支持文档已完成并且是符合要求的

【例15-23上】关于项目变更管理的描述，不正确的是（）。 A.项目范围（工作）和产品范围（工作）定义的过失或者疏忽不属于变更的原因 B.项目规模小、与其他项目的关联度越小时，变更的提出和处理过程可在操作上力求简便、高效 C.变更管理的实质是根据项目情况不断调整项目方向和资源配置，最大程度满足项目需求 D.在项目变更过程控制中，需要对进度变更控制、成本变更控制和合同变更控制等进行重点关注

【例16-23上】文档的规范化管理主要体现在（）方面。 ①文档书写规范②文档质量级别③图表编号规则 ④文档目录编写标准⑤文档管理制度⑥文档安全标准 A.①②③④ B.②③④⑤ C.③④⑤⑥ D.①③④⑤