|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。
|
|
|
|
GB/T 11457—2006中，对“配置管理”的正式定义为：“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置管理员（Configuration Management Officer, CMO）负责在项目的整个生命周期中进行配置管理活动，包括：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 11457—2006对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。”配置项的例子有：交付的软件产品和数据，用于创建或支持软件产品的支持工具，供应商提供的软件和客户提供的设备/软件，各类文档，源代码，可执行代码，测试用例，运行软件所需的各种数据等。
|
|
|
|
在信息系统的开发过程中需加以控制的配置项可以分为基线配置项和非基线配置项两类。例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速、准确地查找到配置项的任何版本。
|
|
|
|
|
|
|
|
|
|
|
|
|
