软考知识点梳理--版本管理

    在配置管理中，所有的配置项都应列入版本控制的范畴。信息系统产品的版本有两个方面的意思，一是为满足不同用户的不同使用要求（例如，如用于不同运行环境 的系列产品，适合Linux，Windows，Solaris用户的软件产品分别称为Linux版，Windows版和Solaris版），它们在功能和 性能上是相当的，原则上没有差别，或者说，这些是并列的系列产品。对于这类差别很小的不同版本，互相也称为变体（variant）。 另一种版本的含义是在信息系统产品投入使用后，产品经过一系列的变更（例如，纠错、增加功能、提高性能等）而形成的一系列的顺序演化的产品，这些产品也称为一个版本，每个版本都可说出它是从哪个版本导出的演化过程。
     修 正后的新版本往往不能完全代替老版本，尽管新版本有某些优越的特性。因为一些用户仍然使用着老版本，并且不容易立刻做到以旧换新，否则可能会打扰老版本原 有的工作环境。显然，多个版本被多个用户同时使用的情况是不可避免的现实。这就要求多个版本共存，这也是配置管理要解决的一个重要课题。
     1. 配置项的状态
     配 置项的状态通常有三种，分别是草稿、正式发布和正在修改。配置项状态变迁如图所示。配置项刚建立时其状态为“草稿”。配置项通过评审（或审批）后，其状态 变为“正式发布”。此后若更改配置项，必须依照变更控制流程执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为 “正式发布”，如此循环。
     2. 版本号表示规则
    版本管理要解决的第一个问题是版本标识，也就是为区分不同的版本，要给它们科学的命名。通 常有两种版本命名的方法，分别是号码版本标识和符号版本标识。其中，号码版本标识以数字表示，例如，用1.0，2.0，1.2，2.1.1等表示版本号； 符号版本标识是将重要的版本属性有选择地给出，例如，SQL Server 2013，Office 2013，将版本产生的时间给出。为了从版本标识上看到更多信息，可能给出更多的属性，例如，面向的客户群、开发语言、硬件平台、生成日期等。
    作为一个例 子，下面介绍一种常见的版本号表示规则。
    （2.1）处于草稿状态的配置项的版本号格式为0.YZ，其中，YZ的数字范围为01-99。随着草稿的不断完善，YZ的取值应递增。YZ的初值和增幅由开发者自己把握。
   （2.2） 处于正式发布状态的配置项的版本号格式为X.Y，其中，X为主版本号，取值范围为l-9。Y为次版本号，取值范围为1-9。配置项第一次正式发布时，版本 号为1.0。如果配置项的版本升级幅度比较小，则一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值。
   （2.3）处于正在修改状态的配置项的版本号格式为X.YZ，配置项在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态重新成为正式发布时，将Z值设置为0，增加 X.Y值。
     3. 版本控制的流程
    一般来说，配置项版本控制的流程如下：
   （3.1）创建配置项。项目团队成员根据配置管理计划，在配置库中创建属于其任务范围内的配置项。此时配置项的状态为“草稿”，其版本号格式为0.YZ。
  （3.2）修改处于草稿状态的配置项。项目团队成员使用配置管理软件的检入（Check In）/检出（Check Out）功能，可以自由修改处于草稿状态的配置项（不受变更控制流程的约束），版本号格式为0.YZ。
   （3.3）技术评审或领导审批。如果配置项是技术文档，则需要接受技术评审；如果配置项是计划类文件，则需要项目经理（或上级领导）的审批。若配置项通过了技术评审或领导审批，则转向步骤（4），否则转向步骤（2）。
   （3.4）正式发布。配置项通过技术评审或领导审批之后，则配置项的状态从“草稿”变迁为“正式发布”，版本号格式为X.Y。
   （3.5） 变更，修改版本号。修改处于正式发布状态的配置项，必须按照变更控制流程执行。如果 CCB同意变更，则配置项状态从“正式发布”变迁为“正在修改”。项目团队成员使用检入/检出功能，可以修改处于正在修改状态的配置项，版本号格式为 X.YZ。修改完毕后，该配置项要重新接受技术评审或领导审批，转向步骤（3）。