软考高项-配置管理知识要点

1、配置管理可能出现的问题：
(1)未建立配置管理系统和机制，配置管理混乱
(2)未设置专门的配置管理员，对配置进行综合管理
(3)没有做好整体版本管理
(4)没有建立基线，导致需求、设计、编码无法对应
(5)没有做好变更管理
(6)缺乏项目整体管理的权衡；
(7)缺乏各种单元测试和集成测试。
(8)配置管理，人员经验不足
(9)对配置管理工具没有进行有效评估
(10)未进行配置工具使用及配置管理的培训
(11)未制定配置管理计划
(12)未建立配置管理机制及权限管理，配置管理较乱
(13)没有定义配置管理流程

2、配置管理问题的应对措施(应如何做好配置管理):
(1)组建配置管理委员会，必要时加强对配置人员的培训或引进有经验人员 (2)引进配置管理工具并进行有效评估
(3)制定有效的配置管理计划
(4)建立配置管理机制，严格进行权限管理
(5)做好配置工作，包括识别配置项、建立基础、做好版本管理等。
(6)定义合理的配置管理流程，制定合理的变更控制流程
(7)识别配置项，并为配置项建立惟一-标识，保证其可追溯
(8)建立配置基线，使重要配置项处于受控状态
(9)定期提交配置状态报告，改进配置管理方法

3、配置管理包括6个主要活动：
(1)制订配置管理计划；
(2)配置项识别
(3)配置项控制
(4)配置状态报告
(5)配置审计
(6)配置管理回顾与改进

4、 典型配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、 测试用例、运行软件所需的各种数据、设备型号及其关键部件等，它们经评审和检查通过后进 入软件配置管理

5、配置项的状态有三种： 草稿、正式发布和正在修改。
配置项刚建立时其状态为“草稿”。配置项通过评审(或审批)后，其状态变为“正式发布”。此 后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。当配置项修改 完毕并重新通过评审(或审批)时，其状态又变为“正式发布”,如此循环。

6、配置库可以分开发库、受控库、产品库
①开发库，也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实 体 ，动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的 修改。(可以任意的修改
②受控库，也称为主库， 包 含当前的基线加上对基线的变更。受控库中的配置项被置于完 全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。 (存放阶段性产物的，可以修改，需要走变更流程)
③产品库，也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置 于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库 内，等待交付用户或现场安装。(存放最终产品的， 一般不再修改，真要修改的话需要走变更 流程)
【口诀】:开发库(动态库)受控库(主库),产品库(静态库)

7、配置库的建库模式有两种：按配置项类型建库和 按任务建库：
①按配置项的类型分类建库，适用于通用软件的开发组织。在这样的组织内，往往产品的 继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的 统一管理和控制，同时也能提高编译和发布的效率。
②按开发任务建立相应的配置库，适用于专业软件的开发组织。在这样的组织内，使用的 开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分类存储，人 为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。

8、 在软件升级过程中的配置库变更控制流程
(1)将待升级的基线从产品库中取出，放入受控库。
(2)程序员将欲修改的代码段从受控库中检出 (cheek out), 放入自己的开发库中进行修改。
代码被 Check out 后即被"锁定",以保证同一段代码只能同时被一个程序员修改，如果甲正对 其修改，乙就无法 Check out。
(3)程序员将开发库中修改好的代码段检入 (Checkin) 受控库。Cheekin 后，代码的"锁定" 被解除，其他程序员可以 Check out 该段代码了。
(4)软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中。

9、配置管理数据库主要内容包括： .
①发布内容，包括每个配置项及其版本号；
②经批准的变更可能影响到的配置项；
③与某个配置项有关的所有变更请求；
④配置项变更轨迹；⑤特定的设备和软件；
⑥计划升级、替换或弃用的配置项；
⑦与配置项有关的变更和问题；
⑧来自于特定时期特定供应商的配置项；
⑨ 受 问 题 影 响 的 所 有 配 置 项 。

10、 配置审计为了确保项目配置管理有效性，不允许出现任何混乱现象，如：
(1)防止向用户提交不适合的产品，如交付了用户手册的不正确版本；
(2)发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更； (3)找出各配置项间不匹配或不相容的现象；
(4)确认配置项己在所要求的质量控制审核之后纳入基线并入库保存；
(5)确认记录和文档保持着可追溯性。

11、(1)功能配置审计。功能配置审计是审计配置项的一致性(配置项的实际功效是否与其需 求一致),具体验证主要包括：①配置项的开发已圆满完成；②配置项已达到配置标识中规定的 性能和功能特征；③配置项的操作和支持文档已完成并且是符合要求的等。
(2)物理配置审计。物理配置审计是审计配置项的完整性(配置项的物理存在是否与预期一致), 具体验证主要包括：①要交付的配置项是否存在；②配置项中是否包含了所有必需的项目等。