知识精讲
考点1: 软件文档一般分为三类：开发文档、产品文档、管理文档。
(1) 开发文档描述开发过程本身，基本的开发文档包括：
1)可行性研究报告和项目任务书。
2)需求规格说明。
3)功能规格说明。
4)设计规格说明，包括程序和数据规格说明。
5)开发计划。
6)软件集成和测试计划
7)质量保证计划。
8)安全和测试信息。
(2) 产品文档描述开发过程的产物，基本的产品文档包括：
1)培训手册。
2)参考手册和用户指南。
3)软件支持手册。
4)产品手册和信息广告。
(3) 管理文档所记录的项目管理信息：
1)开发过程的每个阶段的进度和进度变更的记录。
2)软件变更情况的记录。
3)开发团队的职责定义。
4)项目计划、项目阶段报告。
5)配置管理计划。
考点2: 文档的质量可以分为四级：
(1)最低限度文档(1级文档), 适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发 记录、测试数据和程序简介。
(2)内部文档(2级文档),可用于没有与其他用户共享资源的专用程序。 除1级文档提供的信息外，2级文档还 包括程序清单内足够的注释以帮助用户安装和使用程序。
(3)工作文档(3级文档), 适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。
(4)正式文档(4级文档), 适合那些要正式发行供普遍使用的软件产品。 关键性程序或具有重复管理应用性质(如 工资计算)的程序需要4级文档。4级文档遵守GB/T 8567-2006 的有关规定。
考点3:配置管理包括6个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。
考点4: 典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各 种数据，它们经评审和检查通过后进入配置管理。配置项可以分为基线配置项和非基线配置项两类，例如，基线配 置项可能包括所有的设计文档和源程序等 ；非基线配置项可能包括项目的各类计划和报告等。
考点5: 所有配置项的操作权限应由CMO 严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线 配置项向PM、CCB 及相关人员开放。
考点6:配置项的状态可分为“草稿” “正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。
当配置项修改完毕并重新通过评审时，其状态又变为“正式”。如图所示
配置项状态变化
考点7: 配置项版本号：
(1) 处于“草稿”状态的配置项的版本号格式为0.YZ,YZ 的数字范围为01~99。随着草稿的修正， YZ 的取值应递增°YZ 的初值和增幅由用户自己把握。
(2) 处于“正式”状态的配置项的版本号格式为X.Y,X 为主版本号，取值范围为1~9。
Y 为次版本号，取值范围为0～9。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小， 可以将变动部分制作成配置项的附件，附件版本依次为1.0,1.1, … 。当附件的变动积累到一定程度时，配置项的Y值可适量增加， Y 值增加一定程度时， X 值将适量增加。当配置项升级幅度比较大时，才允许直接增大 X 值 。
(3) **处于“修改”状态的配置项的版本号格式为X.YZ。**配置项正在修改时， 一般只增大Z 值 ，X.Y 值保持不变。
当配置项修改完毕，状态成为“正式”时，将Z 值设置为0,增加 X.Y 值。参见上述规则(2)。
考点8: 配置项版本管理：在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”,所以不能抛弃旧版本。版本管理 的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配 置项的任何版本。
考点9: 配置基线(常简称为基线)由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项 被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。
考点10: 一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基 线。产品的一个测试版本(可能包括需求分析说明书、概要设计说明书、详细设计说明书、己编译的可执行代码、测试大纲、测试用例、使用手册等)是基线的一个例子。
考点11: 一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线，内部开发使 用的基线一般称为构造基线。
考点12:配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具。配置库可以分开发库、受控库、产品库3种类型。
(1) 开发库，也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如新模块、文档、 数据元素或进行修改的己有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发 人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制，因 为这通常不会影响到项目的其他部分。可以任意的修改
(2) 受控库， 也称为主 库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在 信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。 可以修改，需要走变更流程。
(3) 产品库，也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。 在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。 一般不再修改，真要修改的话需要走变更流程。
考点13: 运维过程中修改流程：
(1)将待升级的基线(假设版本号V3.2) 从产品库中取出，放入受控库。
(2)程序员将欲修改的代码段从受控库中检出(Checkout), 放入自己的开发库中进行修改。代码被 Checkout 后 即 被"锁定",以保证同一段代码只能同时被一个程序员修改，如果甲对其修改，乙就无法 Checkout。
(3)程序员将开发库中修改好的代码段检入(Checkin) 受控库。 Checkin 后，代码的锁定被解除，其他程序员可以 Checkout 该段代码了。
(4)软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中(软件产品的版本号更新为 V3.3, V3.2 版并不删除，继续在产品库中保存)。
图14-3 基于配置库的变更控制
考点14:配置库的建库模式有两种：按配置项类型建库和按任务建库。
(1)按配置项的类型分类建库，适用于通用软件的开发组织。使用这样的库结构有利于对配置项的统一管理和控制， 同时也能提高编译和发布的效率。
(2)按开发任务建立相应的配置库，适用于专业软件的开发组织。
考点15: 配置库权限设置：配置管理员负责为每个项目成员分配对配置库的操作权限。
考点16:配置控制委员会负责对配置变更做出评估、审查以及监督已批准变更的实施。 CCB 其成员可以包括项目经 理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。 CCB 不必是常设机构，完全 可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的CCB。 小的项目CCB 可以只有一个人，
甚至只是兼职人员。通常， CCB不只是控制配置变更，而是负有更多的配置管理任务， 例如：配置管理计划审批、 基线设立审批、产品发布审批等。
考点17:配置管理员负责在整个项目生命周期中进行配置管理活动，具体有：
(1)编写配置管理计划。
(2)建立和维护配置管理系统。
(3)建立和维护配置库。
(4)配置项识别。
(5)建立和管理基线。
(6)版本管理和配置控制。
(7)配置状态报告。
(8)配置审计。
(9)发布管理和交付。
(10)对项目成员进行配置管理培训。
考点18:****配置管理系统是用来进行配置管理的软件系统，其目的是通过确定配置管理细则和提供规范的配置管理软 件，加强信息系统开发过程的质量控制，增强信息系统开发过程的可控性，确保配置项(包括各种文档、数据和程 序)的完备、清晰、 一致和可追踪性，以及配置项状态的可控制性。
考点19: 软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。高级项目经理应确保以下配置管理目标得以实现。
(1)确保软件配置管理计划得以制订，并经过相关人员的评审和确认。
(2)应该识别出要控制的项目产品有哪些，并且制定相关控制策略，以确保这些项目产品被合适的人员获取。
(3)应制定控制策略，以确保项目产品在受控制范围内更改。
(4)应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件基线的状态和内容。
考点20:配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础。配置控制委员会负责审批 该计划。配置管理计划的主要内容为：
(1)配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付。
(2)实施这些活动的规范和流程。
(3)实施这些活动的进度安排。
(4)负责实施这些活动的人员或组织，以及他们和其他组织的关系。
考点21: 配置标识也称配置识别，包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征。配置标识 是配置管理员的职能，基本步骤如下。
(1)识别需要受控的配置项。
(2)为每个配置项指定唯一性的标识号。
(3)定义每个配置项的重要特征。
(4)确定每个配置项的所有者及其责任。
(5)确定配置项进入配置管理的时间和条件。
(6)建立和控制基线。
(7)维护文档和组件的修订与产品版本之间的关系。
考点22:创建基线或发行基线的主要步骤如下：(1)配置管理员识别配置项；(2)为配置项分配标识；(3)为项目创 建配置库，并给每个项目成员分配权限；(4)各项目团队成员根据自己的权限操作配置库；(5)创建基线或发行基线 并获得 CCB 的授权。
考点23:配置控制即配置项和基线的变更控制，包括下述任务： 标识和记录变更申请，分析和评价变更，批准或
否决申请，实现、验证和发布已修改的配置项。
(1)变更评估： CCB 负责组织对变更申请进行评估并确定以下内容。
1)变更对项目的影响。
2)变更的内容是否必要。
3)变更的范围是否考虑周全。
4)变更的实施方案是否可行。
5)变更工作量估计是否合理。
6)CCB 决定是否接受变更，并将决定通知相关人员。
(2)基于配置库的变更控制
图14-3 基于配置库的变更控制
考点24:配置状态报告也称配置状态统计， 其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确 地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。配置状态报告应该包含以下内容。
(1)每个受控配置项的标识和状态。 一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和 状态。
(2)每个变更申请的状态和已批准的修改的实施状态。
(3)每个基线的当前和过去版本的状态以及各版本的比较。
(4)其他配置管理过程活动的记录。
配置状态报告应着重反映当前基线配置项的状态，以向管理者报告系统开发活动的进展情况。配置状态报告应定期 进行，并尽量通过 CASE 工具自动生成，用数据库中的客观数据来真实地反映各配置项的情况
考点25:****配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致 性和完整性。配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求不允许出现任何混 乱现象，例如：
- 防止向用户提交不适合的产品，如交付了用户手册的不正确版本。
- 发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。
- 找出各配置项间不匹配或不相容的现象。
- 确认配置项己在所要求的质量控制审核之后纳入基线并入库保存。
- 确认记录和文档保持着可追溯性。
(1) 功能配置审计是审计配置项的一致性(配置项的实际功效是否与其需求一致),具体验证以下几个方面。
- 配置项的开发己圆满完成。
- 配置项已达到.配置标识中规定的性能和功能特征。
- 配置项的操作和支持文档已完成并且是符合要求的。
(2) 物理配置审计是审计配置项的完整性(配置项的物理存在是否与预期一致),具体验证如下几个方面。
- 要交付的配置项是否存在。
- 配置项中是否包含了所有必需的项目。
考点26: 发布管理和交付活动的主要任务是：有效控制软件产品和文档的发行和交付，在软件产品的生存期内妥善保存代码和文档的母拷贝。
(1)存储。
(2)复制。
(3)打包。应确保按批准的规程制备交付的介质。应在需方容易辨认的地方清楚标出发布标识。
(4)交付。供方应按合同中的规定交付产品或服务。
(5)重建。应能重建软件环境，以确保发布的配置项在所保留的先前版本要求的未来一段时间里是可重新配置的。
历年真题
2020年05月全国卷-配置管理员小张注意到某配置项当前版本号为0.68,他马上推断出该配置项目处于(60)状态 A.草稿。
B.变更
C.修改
D.正式
【参考答案】: A
【解析】“草稿”[0.YZ]
2020年05月全国卷-关于配置审计的描述，不正确的是(61)
A.配置审计的实施是为了确保项目配置管理的有效性
B.功能配置审计需验证配置项的开发已圆满完成
C.功能配置审计需验证要交付的配置项是否存在。
D.物理配置审计需验证配置项是否包含所有必需的项目
【参考答案】: C
【解析】物理配置审计是审计配置项的完整性(配置项的物理存在是否与预期一致),具体验证如下几个方面：(1) 要交付的配置项是否存在。(2)配置项中是否包含了所有必需的项目。
2020年05月广东卷-所有配置顶的操作权限应归(60)严格管理。
A、 项目经理
B、QA
C、 测试经理
D、配置管理员。
答案： D
解析：记住就好
2020年05月广东卷- (61)可以确保存储配置项的完整性。
A.确保发布用的介质不含无关项
B.按批准的规程制备交付的介质
C.在容易辨认的地方清楚地标出存储标识
D.将副本存储在不同的受控场所。
答案： D
解析：应通过下述方式确保存储的配置项的完整性：
(1)选择存储介质使再生差错或损坏降至最低限度；
(2)根据媒体的存储期，以一定频次运行或刷新己存档的配置项；
(3)将副本存储在不同的受控场所，以减少丢失的风险。
2021-11- (61)确保了项目配置管理的有效性，体现了配置管理的最根本要求，即不允许出现任何混乱现象。
A.配置审计
B.配置控制
C.配置标识
D.配置控制
【参考答案】 A
【解析】配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求一不允许出现任何混乱 现象。
2021-11- (14)活动要为识别的配置项及其版本建立基线。
A.软件配置标识
B.软件配置发布
C.软件配置控制
D.软件配置状态记录
【参考答案】 A
【解析】软件配置标识活动识别要控制的配置项，并为这些配置项及其版本建立基线。软件配置控制关注的是管理 软件生命周期中的变更。软件配置状态记录标识、收集、维护并报告配置管理的配置状态信息。软件配置审计是独 立评价软件产品和过程是否遵从已有的规则、标准、指南、计划和流程而进行的活动。软件发布管理和交付通常需 要创建特定的交付版本，完成此任务的关键是软件库。
2021-05-关于发布管理和交付的描述，不正确的是：(61)
A.应将正本和副本储存在同一受控场所，以减少丢失的风险。
B.应确保发布用的介质不含无关项
C.应在需方容易辨认的地方清楚地标出发布标识
D.应能重建软件环境，以确保发布的配置项在所保留的先前版本要求的未来一段时间里是可重新配置
【参考答案】 A
【解析】应将副本存储在不同的受控场所，以减少丢失的风险。
2021-05-关于配置管理的描述，不正确的是：(60)
A.配置项通过评审后，其状态变为“正式”
B.配置项第一次成为“正式”文件时，版本号为0.1。
C.所有配置项都应该按照相关规定统一编号
D.一个产品可以有多个基线，也可以只有一个基线
【参考答案】 B
【解析】配置项第一次成为"正式"文件时，版本号1.0
2020-11- (61)不属于发布管理与交付活动的工作内容。
A.检入
B、复制
C、存储
D、打包
【参考答案】 A
【解析】发布管理与交付包含：存储、复制、打包、交付、重建
2020-11-关于配置管理的描述，不正确的是(60)。
A、配置顶的状态分为， “草稿”和“正式”两种。
B、所有配置项的操作权限应由配置管理员严格管理
C、配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体
D、配置库可分为开发库、受控库、产品库三种类型
【参考答案】 A
【解析】草稿、正式、正在修改三种
2019-11- (61) 不属于发布管理与交付活动的工作内容
A、检入
B、复制
C、存储
D、打包
【参考答案】 A
【解析】发布管理与交付包含：存储、复制、打包、交付、重建
