标签：状态 配置管理 配置 软考 基线 文档 高项 变更

14.1 信息系统项目文档及其管理 14.1.1信息系统项目相关信息（文档）

1. 软件文档分类

1. 开发文档 开发文档描述开发过程本身

基本的开发文档包括⭐

1. 可行性研究报告和项目任务书
2. 需求规格说明书
3. 功能规格说明书
4. 设计规格说明，包括程序和数据规格说明
5. 开发计划
6. 软件集成和测试计划
7. 质量保证计划
8. 安全和测试信息
• 产品文档 产品文档描述开发过程的产物

基本产品文档包括⭐

1. 培训手册
2. 参考手册和用户指南
3. 软件支持手册
4. 产品手册和信息广告
• 管理文档 管理文档记录项目管理信息

基本管理文档包括⭐

1. 开发过程的每个阶段的进度和进度变更的记录
2. 软件变更情况的记录
3. 开发团队的指责定义
4. 项目计划、项目阶段报告
5. 配置管理计划
• 文档质量可以分四级
1. 最低限度文档（1级文档）⭐ 适合开发工作量低于一个人月的开发者自用程序，该文档应包含程序清单、开发记录、测试数据和程序简介
2. 内部文档（2级文档）⭐ 可用于没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用
3. 工作文档（3级文档）⭐ 适用于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序
4. 正式文档（4级文档）⭐ 适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重要管理应用性质（如工资计算）的程序需要4级文档

14.2配置管理

1. 定义 应用技术和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性
2. 配置管理包括6个主要活动
1. 指定配置管理计划
2. 配置识别
3. 配置控制
4. 配置状态报告
5. 配置审计
6. 发布管理和交付

  14.2.1配置管理的概念

1. 典型的配置项⭐

包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，他们经评审和检查通过后进入配置管理。

2. 配置项分类⭐
1. 基线配置项⭐ 基线配置项可能包括所有的设计文档和源程序等
2. 非基线配置项⭐ 非基线配置项可能包括项目的各类计划和报告等
3. 配置项的权限⭐

所有配置项的操作权限应由CMO(配置管理员)严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB（变更控制委员会）及相关人员开放。

4. 配置项的状态⭐

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

5. 配置项的版本号⭐
1. 草稿⭐

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

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

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

6. 配置项版本管理⭐
1. 在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本
2. 版本管理的目的是按照一定的规则保存配置的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地找到配置项的任何版本。
7. 配置基线⭐
1. 配置基线（通常称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能在被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。
2. 一组拥有唯一标识号的需求、设计、源代码文件以及相应的可执行代码、构造文件和用户文档构成一条基线。产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子。
3. 一个产品可以由多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线，内部开发使用的基线一般称为构造基线。
8. 配置库⭐⭐
1. 定义 存放配置项并记录配置项相关的所有信息，是配置管理的有利工具
2. 分类
1. 开发库⭐

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

2. 受控库⭐

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

3. 产品库⭐

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

3. 配置库的建库模式有两种
1. 按配置项类型建库 按照配置项的类型分类建库，适用于通用软件的开发组织。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率
2. 按任务建库 按开发任务建立相应的配置库，适用于专业软件的开发组织
4. 配置库权限设置 配置管理员（CMO）负责为每个项目成员分配对配置库的操作权限

9. 配置控制委员会⭐
1. 配置控制委员会（CCB）负责对配置变更做出评估、审批以及监督已批准变更的实施
2. CCB其成员可以包括项目经理、用户代表、产品经理、开发工程功师、测试工程师、质量控制人员、配置管理员等
3. CCB不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求不同，组成不同的CCB。小项目CCB可以只有一个人，甚至只是兼职人员
4. 通常CCB不只是控制配置变更，而是富有更多的配置管理任务，例如：配置管理计划审批、基线设计审批、产品发布审批等
10. 配置管理员⭐
1. 配置管理员（CMO）负责在整个项目生命周期中进行配置管理活动
2. 具体活动
1. 编写配置管理计划
2. 建立和维护配置管理系统
3. 建立和维护配置库
4. 配置项识别
5. 建立和管理基线
6. 版本管理和配置管理
7. 配置状态报告
8. 配置审计
9. 发布管理和交付
10. 对项目成员进行配置管理培训
11. 配置管理系统⭐

配置管理系统是用来进行配置管理的软件系统，其目的是通过确定配置管理细则和提供规范的配置管理软件，加强信息系统开发过程的质量控制，增强信息系统开发过程的可控性，确保配置项（包括各种文档、数据和程序）的完备、清晰、一致和可追踪性，以及配置项状态的可控制性。 14.2.2配置管理的目标和方针

1. 软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性
2. 项目经理应确保以下配置管理目标得以实现
1. 确保软件配置管理计划得以制订，并经过相关人员的评审和确认
2. 应该识别除要控制的 项目产品有哪些，并制定相关控制策略，以确保这些项目产品被合适的人员获取
3. 应制定控制策略，以确保项目产品在受控制范围内更改
4. 应该采取适当的工具和方法，确保相关组别的个人能够及时了解到软件基线的状态和内容

14.2.3日常配置管理活动

1. 配置管理计划
1. 配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础。配置控制委员会负责审批该计划
2. 主要内容
1. 配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付
2. 实施这些活动的规范和流程
3. 实施这些活动的进度安排
4. 负责实施这些活动的人员或组织，以及他们和其他组织的关系
2. 配置标识
1. ⭐配置标识也称配置识别，包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征。配置标识是配置管理员的职能。
2. 基本步骤
1. 识别需要受控的配置项
2. 为每个配置项指定唯一性的标识号
3. 定义每一个配置项的重要特征
4. 确定每一个配置项的所有者及其责任
5. 确定配置项进入配置管理的时间和条件
6. 建立和控制基线
7. 维护文档和组件的修订与产品版本之间的关系
3. 配置控制
1. 定义 配置控制即配置项和基线的变更控制，包括下述任务：标识和记录变更申请，分析和评价变更，批准或否决申请，实现、验证和发布已修改的配置项。
2. 配置控制活动
1. 变更评估
1. 评估并确定的内容
1. 变更对项目的影响
2. 变更的内容是否必要
3. 变更的范围是否考虑周全
4. 变更的实施方案是否可行
5. 变更工作量估计是否合理
2. CCB决定是否接受变更，并将决定通知相关人员
2. ⭐基于配置库的变更控制

4. 配置状态报告
1. 定义 配置状态报告也称配置状态统计，其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。
2. 配置报告内容
1. 每个受控配置项的标识和状态 一旦配置项被置于控制下，就应该记录和保存它的每个后继进展的版本和状态
2. 每个变更申请的状态和已批准的修复的实施状态
3. 每个基线的当前和过去版本的状态以及各版本的比较
4. 其他配置管理过程活动的记录
5. 配置审计
1. 定义 配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性
2. 配置审计作用⭐ 配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最基本要求，不允许出现任何混乱的现象
3. 配置审计目的（考过默写）
1. 防止向用户提交不适合的产品，如交付了用户手册的不正确版本
2. 发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更
3. 找出个配置时间不匹配或不相容的现象
4. 确认配置项已在所要求的质量控制审核之后纳入基线并入库保存
5. 确认记录和文档保持着可追溯性
4. 配置审计分类
1. 功能配置审计
1. 功能配置审计师审计配置项的一致性（配置项的实际功效是否与其需求一致）
2. 具体验证的方面
1. 配置项的开发已圆满完成
2. 配置项以达到，配置标识中规定的性能和功能特征
3. 配置项的操作和支持文档已完成并且师符合要求的
2. 物理配置审计
1. 物理配置审计师审理配置项的完整性（配置项的物理存在是否与预期一致）
2. 具体验证方面
1. 要交付的配置项是否存在
2. 配置项中是否包含了所有必须的项目
6. 发布管理和交付
1. 发布管理和交付活动的主要任务是：有效控制软件产品和文档的发行和交付，在软件产品的生命周期内妥善保存代码和文档的母拷贝
2. 涉及活动
1. 存储
2. 复制
3. 打包 应确保按批准的规程制备交付的介质。应在需方容易辨认的地方清楚标出发布标识。
4. 交付 供方应按合同中的规定交付产品或服务
5. 重建 应能重建软件环境，以确保发布的配置项在所保留的先前版本要求的未来一段时间内是可重新配置的

补充考点 功能配置审计 验证一个配置项的实际工作性能是否符合它的需求规格说明 在项目配置项与基线的变更控制中，将变更后的配置项纳入基线，并将变更内容和结果通知相关人是配置管理员的主要工作  

标签：状态,配置管理,配置,软考,基线,文档,高项,变更
来源： https://www.cnblogs.com/pangzili/p/16692703.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。