扫码获取 VIP 码
添加管理员微信获取 VIP 码
配置管理在软考系统集成项目管理工程师考试中是命题密度极高的章节。按照国家标准和官方教材的定义，配置管理是通过技术手段和行政手段对产品及其开发过程与生命周期进行控制与规范的一系列措施。这一定义的核心在"控制"与"规范"：控制意味着对变更的有序管理，规范意味着对流程的制度化约束。
从信息系统工程的角度看，配置管理解决的是一个根本性矛盾：当项目规模膨胀到一定程度时，多人协作产生的文档、代码、设计图纸、测试用例等工件会以爆炸式速度增长，如果没有一套系统化的管理机制，版本混乱、覆盖丢失、基线不清等问题将直接威胁交付质量。配置管理的目标不是消除变更——变更是项目的常态——而是确保每一次变更都可追溯、可审计、可回滚。
教材将配置管理的作用概括为六个方面：标识配置项、控制配置项变更、记录和报告配置状态、验证配置项的完整性和正确性、建立和管理基线、审核配置。配置管理不等于变更管理，二者是包含关系：配置管理包含变更控制，但范畴更大，还包括配置标识、配置状态记录和配置审计等独立活动。
软考对配置管理的考查主要有三种题型。概念辨析题让考生区分配置基线、功能基线、分配基线等相近概念；流程排序题考察四项活动的逻辑顺序；实务判断题给定场景要求判断操作是否合规。三种题型覆盖了从记忆到应用的全部认知层次。
配置项是配置管理的最小管理单元。教材将其定义为"为了配置管理的目的而作为一个独立单元进行管理的硬件、软件、文档或其中某一项的集合"。这个定义传递了两个关键信息：配置项的颗粒度是人为确定的，而非自然形成的；配置项的外延非常宽泛，不仅包括代码和文档，还包括硬件设备、固件、测试数据、环境配置文件乃至交付介质本身。
在实际工程中确定配置项颗粒度是一个需要权衡的决策。颗粒度过粗，一个配置项包含内容过多，变更影响面过大，失去了精细化管理的意义；颗粒度过细，配置项数量激增，配置管理员的工作量指数级增长，反而降低管理效率。教材给出的经验法则是：配置项的颗粒度应保证每个配置项可由单一责任人独立负责，且该配置项的变更不会同时牵动过多其他配置项。一般来说，需求规格说明书、系统设计文档、模块源代码、测试用例、用户手册都是常见的配置项划分单位。
配置项的命名应能唯一标识一个配置项，且通过名称就能推断其归属关系和版本信息。典型结构包含项目代号、子系统标识、文档类型编码和版本号。例如某财务系统的需求规格说明书V1.2版本可能命名为PRJ-FIN-SRS-V1.2，好处在于无需打开内容，仅凭名称就能检索和统计。
命名规范的深层逻辑在于可追溯性。当项目进入维护阶段需要回溯历史版本时，命名混乱将导致极高的查找成本。软考判断题中若出现配置项编号重复、命名规则不统一、版本号缺失等情况，多半是命题人设置的错误。中小型以上项目推荐分段编码，将项目信息、子系统信息和文档类型分层编码，与工作分解结构的层级对应。
识别配置项的时机也容易被忽略。合理做法是分阶段识别：启动时识别需求类和计划类配置项，设计阶段补充设计类配置项，开发阶段追加代码类和测试类配置项，交付阶段纳入用户手册和培训资料。教材将此表述为
配置项在其生命周期中经历三种状态：草稿状态、正式状态和修改状态。这三种状态构成了配置项状态机的全部节点，状态之间的转换有严格规则，是软考选择题的绝对高频考点。
草稿状态是配置项的初始状态。当配置项被首次创建并录入配置管理系统时，它处于草稿状态。在此状态下创建者拥有完全修改权限，可自由编辑内容而无需经过变更控制流程。这个阶段的版本号通常使用0.X格式，如0.1、0.2、0.3，以区别于正式版本。草稿状态的配置项尚未经过正式评审，内容不具有约束力，不能作为后续开发活动的正式依据。
当草稿状态的配置项通过正式技术评审或管理评审后，便进入正式状态。这一转换是单向的，不可逆转。进入正式状态后版本号从1.0开始计数。正式状态下的配置项被纳入配置基线管理，任何修改都不能直接进行，必须通过正式的变更控制流程——提交变更申请、影响评估、变更控制委员会审批、实施变更、验证变更、更新配置状态。正式配置项的内容具有约束力，是项目团队各成员开展工作的权威依据。
修改状态是正式配置项需要变更时进入的临时状态，体现了"变更不可绕开管理流程"的核心思想。正式配置项被批准变更后转为修改状态，修改完成并经评审确认后回到正式状态，版本号升级。命题人常设陷阱：让考生误以为配置项只有草稿和正式两种状态，遗漏修改状态。配置项从正式状态回到草稿状态被明确禁止——否则已评审通过的内容可绕过变更控制被随意修改，彻底违背配置管理宗旨。
配置基线是配置管理中概念密度最高的术语之一，也是软考案例分析和选择题的必考内容。教材对配置基线的定义是：一组经过正式评审和批准的配置项，构成一个相对稳定的逻辑实体，作为后续开发活动的共同基础和变更控制的参照点。这个定义中有三个关键短语："正式评审和批准"意味着基线具有权威性，不可随意修改；"相对稳定的逻辑实体"表明基线是逻辑上的稳定参照而非物理冻结；"变更控制的参照点"揭示了基线的根本功能——它是衡量一切变更的起点。
基线之所以重要，是因为没有基线就无从定义什么是"变更"。假设一个项目有三名开发人员各自维护代码，不存在共同基线时，三个版本合并就无法确定哪个版本正确、哪个属于偏离。基线提供了共同的锚点，一切差异都相对于这个锚点判断。
在软考知识体系中，基线根据建立时所对应的生命周期阶段分为功能基线、分配基线和产品基线三种类型。功能基线在需求分析阶段建立，定义系统"做什么"；分配基线在设计阶段建立，定义"怎么做"的架构方案；产品基线在测试完成后建立，是最终交付产品的配置快照。三种基线的次序固定：先功能基线，再分配基线，最后产品基线——必须先知道做什么才能决定怎么做然后做出东西来。
基线的建立是正式过程：确定候选配置项清单、逐项技术评审、配置控制委员会批准、配置管理员打基线标签。此后配置项的修改必须遵循变更控制流程。基线可被更新，当累积变更达到一定数量后项目可建立新基线取代旧基线，新旧差异即为项目的技术进展。这种滚动机制保证基线始终反映项目当前技术状态。
配置库是配置管理的物理基础设施。教材将配置库明确划分为三个层次：开发库、受控库和产品库。这三层不是物理上的三台服务器，而是逻辑上的三个管理分区，各自承担不同职能，遵循不同的访问控制规则，配置项在它们之间的流转有严格的单向性。
开发库也叫动态库，是开发人员日常工作的空间。在开发库中配置项处于草稿状态或修改状态，开发人员可自由创建、编辑和删除配置项，不必经过变更控制流程。管理权限相对宽松，目的是保证开发效率不受过度管理的拖累。但宽松不等于无序：教材强调即便是开发库中的配置项也应进行基本的版本控制，每次签入签出都要有记录，只是管理力度不及受控库严格。开发库的版本号通常使用0.X格式或带有开发者标识的临时版本号。
受控库也叫主库，是配置管理的核心区域。配置项通过评审进入正式状态后存放在受控库中。受控库中的配置项已纳入基线管理，任何修改必须通过正式变更控制流程。访问权限由配置管理员严格管控，一般开发人员只有只读权限，修改权限仅授予配置管理员或经变更审批的特定人员。受控库中包含的是当前项目正在使用的工作基线——即"当前版本的真相"。开发库到受控库的流转操作称为"检入"，检入意味着一个新的正式版本诞生。
产品库也叫静态库，是已通过全部测试和验证、准备交付或已交付的最终产品配置项的存储区域。从受控库到产品库的流转操作称为"归档"或"发布"。进入产品库的配置项已完成全部质量验证，不再允许任何形式的修改——如需修改，必须在受控库中创建新版本，走完整变更控制流程后重新发布到产品库。产品库中的旧版本作为历史记录永久保留，是配置审计和产品回溯的数据基础。
三层配置库之间的流转方向是单向的：从开发库到受控库，从受控库到产品库，不可逆转。如果产品库中的配置项发现缺陷，绝对不能直接
本篇完！