|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
|
|
|
|
|
|
|
|
配置项刚建立时其状态为“草稿”。通过评审后，状态变为“正式发布”。此后若更改配置项，则其状态变为“正在修改”。当配置项修改完毕并重新通过评审后，其状态又变为“正式发布”，如此循环。
|
|
|
|
|
|
配置项的版本号与配置项的状态紧密相关。版本号规则如下：
|
|
|
|
.处于“草稿”状态的配置项的版本号格式为0.YZ。YZ数字范围为01~99。随着草稿的不断完善，YZ的取值应递增。YZ的初值和增幅由开发者自己把握。
|
|
|
|
.处于“正式发布”状态的配置项的版本号格式为X.Y。X为主版本号，取值范围为1~9；Y为次版本号，取值范围为1~9。配置项第一次正式发布时，版本号为1.0。如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。
|
|
|
|
.处于“正在修改”状态的配置项的版本号格式为X.YZ。配置项在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（5）变更。修改处于正式发布状态的配置项必须按照配置控制流程执行。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。应当记录每个软件配置项的所有历史记录，并记录该软件配置项由何人创建，何人在何时因何原因进行了修改等信息，以及对这些软件配置项版本的进行检索和信息查询等活动。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 11457—2006对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。”配置项的例子有：交付的软件产品和数据，用于创建或支持软件产品的支持工具，供应商提供的软件和客户提供的设备/软件，各类文档，源代码，可执行代码，测试用例，运行软件所需的各种数据等。
|
|
|
|
在信息系统的开发过程中需加以控制的配置项可以分为基线配置项和非基线配置项两类。例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审。
|
|
|
|
|
|
|
|
|
|
|
|
|
