15.文档/配置管理
口袋应试：文档、配置管理一章中，因为每年出题的分数占比不高，所以出题点比较集中。文档管理中主要是：文档的种类、文档的质量等级；配置管理中出题点主要集中在15.2.1这一节，其中包括：配置项状态、配置项版本号（版本号要会看会区分）、配置库的概念和类型。其它内容大家根据个人时间和精力去复习即可。
15.1信息系统项目相关信息（文档）及其管理
15.1.1信息系统项目相关信息（文档）
2.信息系统项目相关信息（文档）种类
软件文档分为三类：开发文档、产品文档、管理文档。
(1) 开发文档描述开发过程本身，基本的开发文档是：
●可行性研究报告和项目任务书；
●需求规格说明
●功能规格说明
●设计规格说明，包括程序和数据规格说明；
●开发计划
●软件集成和测试计划
●质量保证计划；
●安全和测试信息。
(2) 产品文档描述开发过程的产物，基本的产品文档包括：
●培训手册；
●参考手册和用户指南
●软件支持手册
●产品手册和信息广告
(3) 管理文档记录项目管理的信息，例如：
●开发过程的每个阶段的进度和进度变更的记录
●软件变更情况的记录
●开发团队的职责定义。
第二版[email protected]@15.1.1
出题概率：★★★★★
140163、140363、160163、160361、180361
文档的4个质量等级
文档的质量可以分为四级：
(1) 最低限度文档（1级文档），适合开发工作量低于一个人月的开发者自用程序。 该文档应包含程序清单、开发记录、测试数据和程序简介。
(2) 内部文档（2级文档），可用于没有与其他用户共享资源的专用程序。除1级文 档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
(3) 工作文档（3级文档），适合于由同一单位内若千人联合开发的程序，或可被其 他单位使用的程序。
(4) 正式文档（4级文档），适合那些要正式发行供普遍使用的软件产品。关键性程 序或具有重复管理应用性质（如工资计算）的程序需要4级文档。4级文档遵守GB 8567 的有关规定。
出题概率：★★
140315
15.1.2信息系统项目相关信息（文档）管理的规则和方法
信息系统文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编 写标准和文档管理制度等几个方面。
1) 文档书写规范
2) 图表编号规则
3)文档目录编写标准
4)文档管理制度
为了更好地进行信息系统文档的管理，应该建立相应的文档管理制度。特别要注意的是，项目干系人签字确认后的文档要与相关联的电子文档 对应，这些电子文档还应设置为只读。
出题概率：★★★
170361、180161、190161
15.2配置管理
15.2.1配置管理的概念
口袋应试：整体看配置管理的题点非常多，建议15.2.1全部熟练掌握
1.配置项
所有配置项都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定 章节（部分）记录对象的标识信息。在引入配置管理工具进行管理后，这些配置项都应 以一定的目录结构保存在配置库中。
在信息系统的开发流程中需加以控制的配置项可以分为基线配置项和非基线配置 项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包 括项目的各类计划和报告等。
所有配置项的操作权限应由CMO (配置管理员）严格管理，基本原则是：基线配 置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。
出题概率：★★
160164
2.配置项状态
配置项的状态可分为“草稿”、“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。
出题概率：★★★
150165、160362、190360
3.配置项版本号
配置项的版本号规则与配置项的状态相关。
(1)处于“草稿”状态的配置项的版本号格式为O.YZ，YZ 的数字范围为01～99。
随着草稿的修正，YZ 的取值应递增。YZ 的初值和增幅由用户自己把握。
(2)处于“正式”状态的配置项的版本号格式为X.Y，X 为主版本号，取值范围为1～9。Y 为次版本号，取值范围为0～9。
配置项第一次成为“正式”文件时，版本号为1.0。
(3)处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z 值，X.Y 值保持不变。当配置项修改完毕，状态成为“正式”时，将Z 值设置为O，增加X.Y 值。
出题概率：★★★★★
140165、140365、150365、160165、170362
4.配置项版本管理
配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最 终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比 旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照--定的规则保存配置项的所 有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何 版本。
出题概率：★★
130365
5．配置基线
配置基线（常简称为基线）由一组配置项组成，这些配置项构成-1-个相对稳定的逻 辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须 遵循正式的变更控制程序。
一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。产品的一个测试版本（可能包括需求分析说明书、概要设计 说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等） 是基线的一个例子。
出题概率：★
150363
6。配置库
配置库（Configuration Library）存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具，利用库中的信息可回答许多配置管理的问题
使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。
配置库可以分为开发库、受控库、产品库3种类型。
(1)开发库（Development Library），
也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如：新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。
(2)受控库(Controlled Library)，
也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
(3)产品库（Product Library），
也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
配置库的建库模式有两种：
按配置项类型建库和按任务建库。
(1)按配置项的类型分类建库，
适用于通用软件的开发组织。在这样的组织内，产品的继承性往往较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。
(2)按开发任务建立相应的配置库，
适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。
出题概率：★★★★★
170162、170163、180162、180362、190162
9。配置管理员
配置管理员（Configuration Management Officer, CMO),负责在项目的整个生命周期中进行配置管理活动，具体有：
●编写配置管理计划；
●建立和维护配置管理系统；
●建立和维护配置库；
●配置项识别；
●建立和管理基线；
●版本管理和配置控制；
●配置状态报告；
●配置审计；
●发布管理和交付；
●对项目成员进行配置管理培训。
出题概率：★
170160
15.2.3配置标识
配置标识（Configuration Identification)也称配置识别，包括为系统选择配置项并在 技术文档中记录配置项的功能和物理特征。
配置标识是配置管理员的职能，基本步骤如下
(1)识别需要受控的配置项；
(2)为每个配置项指定唯一性的标识号
(3)定义每个配置项的重要特征；
(4)确定每个配置项的所有者及其责任；
(5)确定配置项进入配置管理的时间和条件；
(6)建立和控制基线；
(7) 维护文档和组件的修订与产品版本之间的关系。
出题概率：★★★
130364、150164
15.2.4配置控制
7.基于配置库的变更控制
现以某软件产品升级为例，简述其流程。
(1)将待升级的基线（假设版本号为V2.1）从产品库中取出，放入受控库。
(2)程序员将欲修改的代码段从受控库中检出(cheek out)，放入自己的开发库中进行修改。
(3)程序员将开发库中修改好的代码段检入（Check in）受控库。Cheek in后，代码的“锁定”被解除，其他程序员可以Check out该段代码了。
(4)软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品的版本号更新为V2.2，旧的V2.1版并不删除，继续在产品库中保存）。
出题概率：★
160366
15.2.6配置审计
配置审计(Configuration Audit）也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。
1。功能配置审计
功能配置审计(Functional Configuration Audit)是审计配置项的一致性（配置项的实际功效是否与其需求一致），具体验证以下几个方面。
(1)配置项的开发已圆满完成。
(2)配置项已达到配置标识中规定的性能和功能特征。
(3)配置项的操作和支持文档已完成并且是符合要求的。
2。物理配置审计
物理配置审计(Physical Conflguration Audit)是审计配置项的完整性（配置项的物理存在是否与预期一致），具体验证如下几个方面。
(1)要交付的配置项是否存在。
(2)配置项中是否包含了所有必需的项目。
出题概率：★
180314
15.2.7发布管理和交付
发布管理和交付活动的主要任务是：有效控制软件产品和文档的发行和交付，在软 件产品的生存期内妥善保存代码和文档的母拷贝。
1. 存储
2。 复制
3. 打包
4. 交付
5. 重建
出题概率：★
190361
●更多的备考复习资料，可以查看我的博客：跬步郎的博客 。
以下内容为第一版内容，仅供参考
为了确保软件的实现满足需求需要的基本文档
1、软件需求规格说明书：必须清楚、准确地描述软件的每一个基本需求（功能、性能、设计约束和属性）和外部界面。
2、软件设计说明书：包括软件概要设计说明和软件详细设计说明两部分。
3、软件验证与确认计划：必须描述所采用的软件验证和确认方法
4、软件验证和确认报告：描述软件验证与确认计划的执行结果。
5、用户文档(例如手册、指南等)必须指明成功运行该软件所需要的数据、控制命令以及运行条件等；必须指明所有的出错信息、含义及其修改方法，还必须描述将用户发现的错误或问题通知项目承办单位(或软件开发单位)或项目委托单位的方法。
出题概率：★★
140128、150113
配置管理过程构造小组应该包括如下成员
1、小组负责人。其对整个构造过程负责。主要职责是协调与其他部门或与上级主管的关系， 监督工作进程，协调小组内部关系。
2、技术支持专家。其负责在技术、设备方面为本组提供支持和服务，并负责本组同其他部门就技术问题进行联络，如了解相关项目情况、开发环境和开发人员状况等。
3、配置管理技术专家。其对配置管理过程的构造和配置管理工具十分熟悉。主要任务是指导配置管理过程的构造，帮助制订配置管理规章，负责对开发人员进行配置管理工具的培训。通常由配置管理工具提供商或专门的配置管理顾问机构的人员担当此任。
4、配置管理系统用户代表。他们是从将来要在实际的项目开发过程中使用该系统、遵循该过程的开发人员中挑选出来的。他们负责从构造初期了解配置管理系统和规程，根据开发经验协助制订、修改配置管理规程，并在试验项目中担任部分开发角色。这部分成员应包括软件开发项目经理、设计人员、编码、测试和构造、发布人员。该项目小组成立后，将按后述步骤开展配置管理过程的构造工作。
出题概率：★
140364
建立基线的目的及其在项目实施中的应用
配置项的识别是配置管理活动的基础，也是制定配置管理计划的重要内容。软件配置项分类软件的开发过程是一个不断变化着的过程，为了在不严重阻碍合理变化的情况下来控制变化，软件配置管理引入了“基线”这一概念。根据这个定义，我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。
出题概率：★
140370
