基本概念
配置管理是为了系统的控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，标识系统在不同时间点上配置的学科。“配置管理”正式定义为“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更、记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”
配置管理包括6个主要活动：
-
制定配置管理计划
-
配置标识
-
配置控制
-
配置状态报告
-
配置审计
-
发布管理和交付
软件配置管理是一个支持性的软件生命周期过程，它有益于项目管理、开发和维护活动、各种保证活动、最终产品的客户和用户。尽管硬件配置管理和软件配置管理的实现有所不同，配置管理的概念可以应用于所有要控制的项。软件配置管理包括4个主要活动：配置识别、变更控制、状态报告、配置审计。
配置管理重点关注可交付产品（包括中间产品）及各过程文档，而变更管理则着眼于识别、记录、批准或否决对项目文件、可交付产品或基准的变更。
-
配置项的状态可分为草稿、正式、修改。配置项刚建立时，其状态为”草稿“。配置项通过评审后，其状态变为”正式“。此后若更改配置项，其状态变为”修改“。当配置项修改完毕并重新通过评审时，其状态又变为”正式“。
-
信息系统的开发流程中需要加以控制的配置项可以分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。
-
所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM，CCB及相关人员开放。
-
典型配置项包括：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，他们经评审和检查通过后进入配置管理。
-
草稿：0.YZ YZ的数字范围为01-99，YZ的初始值和增幅值由用户自己把握。
-
正式：X.Y X为主版本号，取值范围1-9，Y为次版本号，取值范围0-9，配置项第一次称为正式文件时版本号为1.0，如果配置项升级幅度较小，可以将变动部分制作成配置项的附件，附件版本一次为1.0，1.1....,当附件的变动积累到一定程度时，配置项的Y值可适量增加，Y值增加到一定程度时，Z值将适量增加。当配置项升级幅度变化较大时，才允许直接增大Z值。
-
修改：X.YZ。配置项正在修改时，一般只增大Z值，X，Y保持不变，当配置项修改完毕，状态变为”正式“时，将Z值设置为0，增加X，Y值。
-
配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。
-
不抛弃旧版本。
-
版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
-
配置基线（简称基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。
-
基线中的配置项被”“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序
-
基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线称为发行基线，内部开发使用的基线一般称为构造基线。
-
要定义的内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需要的权限。在项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。
配置基线的好处：
配置库（Cofiguration Library）存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具，利用库中的信息可回答许多配置管理的问题。配置库可分为开发库、受控库、产品库三种类型。
-
开发库
也称为动态库，程序员库或工作库，用于保存开发人员当前正在开发的配置实体。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。可以任意的修改。
-
受控库
也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。可以修改，需要走变更流程。
-
产品库
也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。一般不再修改，若要修改需走变更流程。
-
按配置项的类型分类建库，适用于通用软件的开发组织。在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。
-
按开发任务建立相应的配置库，适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性开发为主，所以就没有必要把配置项严格的分类存储，认为增加目录的复杂性。对于研发行的软件组织来说，采用这种设置策略比较灵活。
配置库的权限设置主要是解决：库内存储的配置项什么人可以“看”、什么人可以“取”、什么人可以“改”、什么人可以“销毁”等问题。配置管理员负责为每个项目从成员分配对配置库的操作权限。
【配置库的操作权限】
配置管理员
配置管理
配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础应该形成文件并在整个项目生命周期内处于受控状态。配置控制委员会负责审批该计划。
配置管理计划的主要内容为：
-
配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付；
-
实施这些活动的规范和流程。
-
实施这些活动的进度安排。
-
负责实施这些活动的人员或组织，以及他们和其他组织的关系。
配置标识（Configuration Identification）也称配置识别，包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征。
-
识别需要受控的配置项；
-
为每个配置项指定唯一性的标识号；
-
定义每个配置项的重要特征；
-
确定每个配置项的所有者及其责任；
-
确定配置项进入配置管理的时间和条件；
-
建立和控制基线；
-
维护文档和组件的修订与产品版本之间的关系。
-
标识和记录变更申请；
-
分析和评价变更；
-
批准或否决申请；
-
实现；
-
验证和发布已修改的配置项。
配置状态报告也称配置状态统计，其任务是有效地记录和报告管理配置所需的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。
配置状态报告应着重反应当前基线配置项的状态，以向管理者报告系统开发活动的进展情况。配置状态报告应定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实地反映各配置项的情况。
-
每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。
-
每个变更申请的状态和已批准的修改的实施状态。
-
每个基线的当前和过去版本的状态以及各版本的比较。
-
其他配置管理过程活动的记录。
配置审计
-
配置项的开发已圆满完成。
-
配置项已达到配置标识中规定的性能和功能特征。
-
配置项的操作和支持文档已完成并且是否和要求的。
1.存储。应通过下述方式确保存储的配置项的完整性：
-
选择存储介质使再生差错或损坏降到最低限度 -
根据媒体的存储期，以一定频次运行或刷新已存档的配置想 -
将副本存储在不同的受控场所，以减少丢失的风险。
-
应建立规程以确保复制的一致性和完整性。 -
应确保发布用的介质不含无关项（如：软件病毒或者不适合演示的测试数据）。 -
应使用适合的介质以确保软件产品符合复制要求，确保其在整个交付期中内容的完整性。
原文始发于微信公众号（网络安全等保测评）：配置管理
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论