【2027版】第59讲：配置管理、变更管理与项目文档管理

第59讲（上）：锁定"1.0 版"：配置管理

【虚构案例声明】 本课程中的"美好家园"物业集团、"清华园社区"、"智慧邻里2.0"项目及全部人物均为教学所用的虚拟项目与虚构人物，详见第 01 讲首次声明。

一、上节作业讲评

1.1 三个文档问题

上一讲的核心作业：接口文档五个版本散在三个人电脑里说不清哪个是最终版；部署脚本和文档不一致；两处配置改动没人记录查不到是谁改的。三个问题分别对应配置管理的哪项工作没做到；配置项、基线、配置库三者的关系；配置管理和变更管理的分工；如果一开始就做好配置管理，各会在哪个环节被挡住。

第一问，三个问题的归因。第一个是配置项识别和版本管理没做：文档没纳入配置项、没有唯一标识符、没有版本号规则、没进受控库。第二个是配置审计没做，具体说是物理配置审计缺位，交付的东西和文档描述的不一致。第三个是配置项控制和配置状态报告没做：变更没有记录、没有变更轨迹、找不到责任人。

第二问，三者关系。配置项是被管理的单个对象；基线是一组配置项在某个特定时刻构成的相对稳定的逻辑实体，基线里的配置项被冻结；配置库是存放配置项并记录相关信息的地方，分开发库、受控库、产品库三类。一句话：配置项是砖，基线是砌好并封存的一堵墙，配置库是放砖和墙的仓库。

第三问，分工。配置管理管"东西是什么状态"，变更管理管"改不改、谁批的"，第 55 讲讲过配置控制关注技术规范、变更控制关注审批，是同一条线。完整的分工在下篇讲。

第四问，各会在哪挡住。第一个会被配置项识别和配置库检出锁定挡住；第二个会被物理配置审计挡住；第三个会被配置项控制的七个步骤挡住。

这一讲和下一篇是模块七里案例题分值最高的两篇，真题密度极大。

二、配置管理管什么

2.1 定义与两个目的

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

定义里两个关键词：完整性和可跟踪性。这两个词是配置管理的全部目的，所有具体动作都是为了这两件事。完整性是指该有的东西都在、彼此匹配；可跟踪性是指任何一次改动都查得到是谁在什么时候因为什么改的。

教材引用的国家标准把配置管理定义为：应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。

这个定义里"功能和物理特征"这一组词很重要，它对应后面配置审计的两类，即功能配置审计和物理配置审计。定义和审计两处对着记。

教材还引用了另一份国家标准的要求：组织应建立配置管理过程，整体规划配置管理范围，保留配置信息，并保证配置信息的可靠性、完整性和时效性，以对其他服务过程提供支持；应建立与配置管理过程相一致的活动，包括对配置项的识别、收集、记录、更新和审核等。

这一句给出了配置信息的三个质量要求：可靠性、完整性、时效性；以及五个活动动词：识别、收集、记录、更新、审核。

教材最后说：尽管硬件配置管理和软件配置管理的实现有所不同，但配置管理的概念可以应用于各种信息系统项目。

本篇讲配置管理，下篇讲变更管理与项目文档管理。教材把它们放在同一章，因为三件事本质是一件事：让项目的每一份东西都有名有姓、有版本、有归属、改动有记录。这一章是选择题的富矿，也是案例题的高频领域。

2.2 本篇任务地图

三、核心内容精讲：配置管理基础

3.1 配置项与两类划分

配置项的定义，教材引用国家标准：为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。

教材接着说：配置项是信息系统组件或与其有关的项目，包括软件、硬件和各种文档，如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等；这些组件或项目已经或将要受到配置管理的控制。

比较典型的配置项，教材列了九类：项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件。教材强调：它们经评审和检查通过后进入配置管理。

注意"经评审和检查通过后进入"这半句：不是写出来就进配置管理，是评审通过才进。这是一个容易被忽略的时点。

九类典型配置项里，前四类全是文档。这一点对项目经理很重要：很多团队只把代码纳入版本管理，文档散在各人手里，而教材列的典型配置项里文档占了大半。

教材还说：所有配置项都应按照相关规定统一编号，并以一定的目录结构保存在配置管理数据库中。

配置项分两类，这是高频考点。教材口径：在信息系统的开发项目中需加以控制的配置项可以分为基线配置项和非基线配置项两类；基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。

权限规则更是必考：所有配置项的操作权限应由配置管理员严格管理，基本原则是基线配置项向开发人员开放读取的权限，非基线配置项向项目经理、变更控制委员会及相关人员开放。

这条规则要一字不差地记，两个要点：基线配置项对开发人员只开放读取，不是修改；非基线配置项开放给项目经理和变更控制委员会及相关人员，不是开发人员。

2022 年下半年第 49 题问质量管理人员通常有哪些权限，2023 年下半年第 2 批第 29 题问配置管理的说法哪个错误，考的都是这条权限规则。2016 年上半年第 51 题问哪个一般属于非基线配置项，答案在"项目的各类计划和报告"这一侧。

一个理解上的提示：为什么基线配置项对开发人员只读？因为基线一旦确立就被冻结了，开发人员要改必须走变更流程，不能直接改。而非基线配置项如各类计划和报告，是管理层要看和要改的东西，所以对项目经理和委员会开放。权限设计的背后是"谁对这类东西负责"。

3.2 配置项状态与版本号规则

配置项状态三种。教材口径：配置项的状态需要根据配置项的不同类型和管理需求进行分别定义，基于配置项建设过程角度，可将配置项状态分为草稿、正式和修改三种；配置项刚建立时其状态为草稿；配置项通过评审后其状态变为正式；此后若更改配置项则其状态变为修改；当配置项修改完毕并重新通过评审时，其状态又变为正式。

三种状态的循环要记牢：草稿到正式是评审通过，正式到修改是开始改，修改回正式是再次评审通过。注意没有从修改直接回草稿的路径，也没有从草稿直接到修改的路径。2016 年上半年第 64 题问配置项状态的叙述哪个不正确，考的就是这个循环。

版本号规则是要动笔算的一节，教材给了三条规则。

处于草稿状态的配置项，版本号格式为 0.YZ，其中 YZ 是数字，取值范围为 01 到 99；随着草稿的修正，YZ 的取值应递增；YZ 的初值和增幅由用户自己把握。

处于正式状态的配置项，版本号格式为 X.Y，X 为主版本号取值范围 1 到 9，Y 为次版本号取值范围 0 到 9；配置项第一次成为正式文件时版本号为 1.0；如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为 1.0、1.1 等；当附件的变动积累到一定程度时，配置项的 Y 值可适量增加；Y 值增加到一定程度时，X 值将适量增加；当配置项升级幅度比较大时，才允许直接增大 X 值。

处于修改状态的配置项，版本号格式为 X.YZ；配置项正在修改时一般只增大 Z 值，X.Y 值保持不变；当配置项修改完毕、状态成为正式时，将 Z 值设置为 0，增加 X.Y 值。

三条规则的记法：草稿是零点几几，正式是一位小数，修改状态是两位小数且只动最后一位。

举个例子完整走一遍：一份需求规格说明书写初稿是 0.01，改了两轮成 0.03，评审通过成为正式版 1.0；发现三处错误开始修改，状态变为修改，版本号变成 1.01、1.02、1.03；修改完毕重新评审通过，Z 归零、Y 加一，成为 1.1。

2016 年上半年第 63 题给的场景就是这个：需求规格说明书第一次正式发布版本号 1.0，此后由于发现几处错误进行了两次小的升级，问版本号变成什么。按规则算，两次小升级后成为正式状态时 Y 值增加。2015 年上半年第 62 题问创建基线或发布基线的主要步骤，2015 年上半年第 63 题问版本号 1.0 表明什么，考的都是这套规则。

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

"不能保证新版本一定比旧版本好，所以不能抛弃旧版本"这句是版本管理的根本理由，写论文和答案例题都能用。

教材还说：配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。也就是说版本管理不是一个独立环节，它渗透在所有活动里。

3.3 配置基线

教材口径：配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。配置基线也是指一个产品或系统在某一特定时刻的配置状况。这种配置不仅体现了其产品或系统的结构，还反映了其具体内容，从而使得以后可以按照上述配置重建该产品或系统。尽管被作为基准线的这个配置状态以后可能发生改变，但这个基线本身保持不变。这个基线可以作为初始状态的一个参考或当前状态的一个对照。

关键在"基线本身保持不变"这句：基线是一个快照，快照拍下来就不变了；后续的改动产生新的基线，不是修改旧基线。这跟第 55 讲讲的"不能变更以往的绩效"是同一个道理。

教材还列了配置基线的用途：可用于管理对象中的授权产品、标准配置项、开发和测试新配置的起点、作为提供给信息技术系统用户的配置的标准、作为提供新软件的起点等。

教材接着说明为什么需要基线：在信息系统项目过程中，各类配置项存在不断变化的情况，为了在不严重阻碍合理变化的情况下来控制变化，需要使用配置基线这一概念。基线中的配置项被冻结了，不能再被任何人随意修改；对基线的变更必须遵循正式的变更控制程序。

"在不严重阻碍合理变化的情况下来控制变化"这半句是配置管理的分寸所在：不是不让改，是让改得受控。这句话在论文里很好用。

基线的例子，教材给了两个：一组拥有唯一标识号的需求、设计、源代码文档以及相应的可执行代码、构造文档和用户文档构成一条基线；产品的一个测试版本，可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例和使用手册等，也是基线的例子。

基线的种类，教材口径：基线通常对应于项目过程中的里程碑，一个项目可以有多个基线，也可以只有一个基线；交付给用户使用的基线一般称为发行基线，内部过程使用的基线一般称为构造基线。

发行基线和构造基线这两个词要记。2016 年下半年第 12 题问国家标准规定了配置管理的三种基线，这道题是按标准的口径出的，跟教材这里的两分法不是一套，做题时看题干引的是哪个来源。

每个基线要定义的四项内容，这是 2016 年上半年第 50 题的直接考点：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。

四项必背。那道题问哪个不属于基线定义中的内容，把这四项记住就能排除。教材还说：在项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。

建立基线的价值四条：基线为项目工作提供了一个定点和快照；新项目可以在基线提供的定点上建立，新项目作为一个单独分支将与随后对原始项目所进行的变更进行隔离；当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法；可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。

四条里第三条和第四条最实用：基线是后悔药，也是复现问题的手段。没有基线，出了故障连"上一个能用的版本长什么样"都说不清。

3.4 配置管理数据库与三类配置库

配置管理数据库。教材口径：它是指包含每个配置项及配置项之间重要关系的详细资料的数据库。教材说对于信息系统开发项目来说，常使用配置库实施配置数据的管理。

主要内容九项：发布内容包括每个配置项及其版本号；经批准的变更可能影响到的配置项；与某个配置项有关的所有变更请求；配置项变更轨迹；特定的设备和软件；计划升级、替换或弃用的配置项；与配置项有关的变更和问题；来自于特定时期特定供应商的配置项；受问题影响的所有配置项。

教材还说：配置管理数据库管理所有配置项及其关系，以及与这些配置项有关的事件、问题、已知错误、变更和发布及相关的员工、供应商和业务部门信息；保存多种服务的详细信息及这些服务与信息技术组件之间的关系；保存配置项的财务信息，如供应商、购买费用和购买日期等。

"保存配置项的财务信息"这一条常被忽略：数据库里不只有技术信息，还有买了多少钱、什么时候买的、谁供的货。这对运维和资产管理很关键，也是配置管理与采购管理的接口。

配置库。教材口径：配置库存放配置项并记录与配置项相关的所有信息，它是配置管理的有力工具。教材列了利用配置库可回答的六个问题：哪些用户已提取了某个特定的系统版本；运行一个给定的系统版本需要什么硬件和系统软件；一个系统到目前已生成了多少个版本、何时生成的；如果某一特定的构件变更了会影响到系统的哪些版本；一个特定的版本曾提出过哪几个变更请求；一个特定的版本有多少已报告的错误。

这六个问题很值得读一遍，因为它们说明了配置库到底解决什么：不是存文件，是回答"谁在用什么版本、改了会影响谁、这个版本有多少已知问题"。

教材还说：使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。

三类配置库必背：

开发库，也称动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如新模块、文档、数据元素或进行修改的已有元素；动态库中的配置项被置于版本管理之下；动态库是开发人员的个人工作区，由开发人员自行控制；库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无须对其进行配置控制，因为这通常不会影响到项目的其他部分。

受控库，也称主库，包含当前的基线以及对基线的变更；受控库中的配置项被置于完全的配置管理之下；在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。

产品库，也称静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下；在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。

三类的别名要记全，考试常用别名出题：开发库等于动态库等于程序员库等于工作库；受控库等于主库；产品库等于静态库等于发行库等于软件仓库。

三类的控制程度也要记：开发库只做版本管理、无须配置控制；受控库和产品库都置于完全的配置管理之下。这个差别的道理是：开发库里的东西还在个人手上，改了不影响别人；进了受控库就是团队共享的东西，必须受控。

建库模式两种：

按配置项的类型分类建库，适用于通用软件的开发组织。教材说在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求；使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率；但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。

按开发任务建立相应的配置库，适用于专业软件的开发组织。教材说在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以没必要把配置项严格分类存储、人为增加目录的复杂性；对于研发性的软件组织来说，采用这种设置策略比较灵活。

两种模式的适用对象要分清：通用软件组织按类型建库，专业软件组织按任务建库。判断的关键词是"产品继承性强、工具统一、有并行开发需求"对应按类型，"开发工具种类繁多、线性发展"对应按任务。

3.5 基于配置库的变更控制

教材用一个具体故事讲清了为什么需要这套机制，这个故事是案例题的常见原型。

教材原文的情形：在软件测试时发现了两个故障，项目经理最初以为两故障是无关联的，就分别指定甲和乙去解决这两个故障；但碰巧引起这两个故障的错误代码都在同一个软件部件中；甲和乙各自对故障定位后，先后从库中取出该部件，各自做了修改，又先后将部件送回库中；结果甲放入库中的部件版本只有甲的修改，乙放入库中的部件版本只有乙的修改，没有一个版本同时解决了两个故障。

这就是不做检出锁定的后果：后改的人覆盖了先改的人，而且两个人都以为自己改好了。

教材还说：在信息系统开发项目中，一处出现了变更经常会连锁引起多处变更，会涉及到参与开发工作的许多人员；例如测试引发了需求的修改，那么很可能要涉及到需求规格说明、概要设计、详细设计和代码等相关文档，甚至会使测试计划随之变更。

这一段说明了配置管理的另一个价值：追踪连锁影响。改一处要知道牵动哪些，靠的是配置项之间的关系记录。

教材给的四步流程，以某软件产品升级为例，这四步是排序题的直接考点：

将待升级的基线，假设版本号为 2.1，从产品库中取出，放入受控库。

程序员将欲修改的代码段从受控库中检出，放入自己的开发库中进行修改；代码被检出后即被锁定，以保证同一段代码只能同时被一个程序员修改。

程序员将开发库中修改好的代码段检入受控库；检入后代码的锁定被解除，其他程序员可以检出该段代码了。

软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中，软件产品的版本号更新为 2.2，旧的 2.1 版并不删除、继续在产品库中保存。

四步的方向要记死：产品库到受控库到开发库，改完再开发库到受控库到产品库。出去一趟再回来，路径对称。

三个考点：检出即锁定，同一段代码同时只能一个人改；检入解除锁定；旧版本不删除、继续在产品库中保存。