第十四章 配置项管理

一、信息系统项目文档及其管理

1. 软件文档的分类

1. 开发文档【描述开发过程本身】
   • 可行性研究报告和项目任务书
   • 需求规格说明
   • 功能规格说明
   • 设计规格说明，包括程序和数据说明
   • 开发计划
   • 软件集成和测试计划
   • 质量保证计划
   • 安全和测试信息
2. 产品文档【描述开发过程的产物】
   • 培训手册
   • 参考手册和用户指南
   • 软件支持
   • 产品手册和信息广告
3. 管理文档【记录项目管理的信息】
   • 开发过程的每个阶段的进度和进度变更的记录
   • 软件变更情况的记录
   • 开发团队的职责定义
   • 项目计划、项目阶段报告
   • 配置管理计划

2. 文档质量的四个等级

1. 最低限度文档【1级文档】
   • 适合开发工作量低于一个人月的开发者自用程序。
   • 该文档应包含程序清单、开发记录、测试数据和程序简介
2. 内部文档【2级文档】
   • 可用于没有与其他用户共享资源的专用程序。
   • 还包括程序清单内足够注释以帮助用户安装和使用程序
3. 工作文档【3级文档】
   • 适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序
4. 正式文档【4级文档】
   • 适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重要管理应用性质（如工资计算）的程序

二、配置管理

概述

软件配置管理关心：文件的各个历史版本是否记录下来了，以便今后翻阅；各次修改的修改者、修改的原因是否记录下来了，以便将来理解当时的情形，理解为什么做出这样的改动

1. 配置项

• 配置项是可以修改的

  • 项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据。他们经过评审和检查通过后进入配置管理。
  • 不可修改的不能作为配置项：测量报告、会议纪要、工作报告

• 配置项分为基线配置项和非基线配置项

  • 基线配置项：可能包括所有的设计文档和源程序等，例：系统开发过程的各个版本
  • 非基线配置项：可能包括项目的各类计划和报告等

• 所有配置项的操作权限应有CMO(配置管理员)严格管理。基本原则是：

  • 基线配置项向开发人员开放读取权限；
  • 非基线配置项向PM(项目经理)、CCB(控制变更委员会)和相关人员开放

2. 配置项状态和版本号

• 三种状态：草稿、正式、修改。配置型刚建立时，其状态为“草稿”。通过评审后，变为“正式”。此后若更改配置项，状态变为“修改”。当配置项修改完毕并重新通过评审，状态变为“正式”。

  • “草稿”状态：0.YZ。
  • “正式”状态：X.Y。 X取值1-9
  • “修改”状态：X.YZ。 X取值1-9
    

• 配置项的版本管理

  • 目的：按照一定的规则保存配置项的所有版本
  • 由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本

3. 配置基线

• 由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项不能被任何人随意修改。对基线的变更要遵循正式的变更控制程序
• 一个产品可以有多个基线，也可以只有一个基线
  • 发行基线：交付给外部顾客
  • 构造基线：内部开发使用

4. 配置库

• 开发库：动态库、程序员库、工作库

  • 用于保存开发人员当前正在开发的配置实体，库中的信息可能有较为频繁的修改。
  • 可以任意修改

• 受控库：主库

  • 在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。包含当前的基线和对基线的变更。
  • 存放阶段性产物的，可以修改，需要走变更流程

• 产品库：静态库、发行库、软件仓库

  • 在信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。包含已发布使用的各种基线的存档。
  • 存放最终产品的，一般不再修改，真要修改的话需要走变更流程

5. 配置库的权限设置

1. 受控库权限设置
   
2. 产品库权限设置
   

6. 配置控制委员会(CCB)

1. 配置控制委员会：负责对配置变更做出评估、审批以及监督已批准变更的实施。
2. 成员：项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB不是常设机构，小的项目CCB可以只有一个人，甚至只是兼职人员。
3. CCB是决策机构，不是执行机构。

7. 配置管理员(CMO)

• 配置管理员：负责在整个项目生命周期中进行配置管理活动。具体有：
  • 编写配置管理计划
  • 建立和维护配置管理系统
  • 建立和维护配置库
  • 建立和管理基线
  • 版本管理和配置控制
  • 配置状态报告
  • 配置审计
  • 发布管理和交付
  • 对项目成员进行配置管理培训

8. 配置管理的6个主要活动

• 制订配置管理计划：写一个文档，规定如何做好配置管理
• 配置标识：识别出需要把哪些东西作为配置项来管理
• 配置控制：配置项有一些变更，需要做好配置变更的控制
• 配置状态报告：需要报告配置项的状态是什么样的
• 配置审计：做好审计，看看有哪些好的、不好的经验教训，效果怎样
• 发布管理和交付：注意发布和交付过程，妥善保存好代码和文档的母拷贝

1. 制订配置管理计划

   • 软件配置管理是在贯穿于整个软件生命周期中建立和维护项目产品的完整性。
   • 配置管理计划有配置管理员制定，配置控制委员会负责审批

2. 配置标识

   • 识别需要受控的配置项
   • 为每个配置项指定唯一性的标识号
   • 定义每个配置项的重要特征
   • 确定每个配置项的所有者及其责任
   • 确定配置项进入配置管理的时间和条件
   • 建立和控制基线
   • 维护文档和组件的修订与产品版本之间的关系

3. 配置控制

   • 配置项和基线的变更控制，包括：标识和记录变更申请，分析和评价变更，批准或否决申请，实现、验证和发布已修改的配置项。

   • 以某软件产品升级为例，其流程为：

     • (1) 将待升级的基线从产品库中取出，放入受控库；
     • (2) 程序员将欲修改的代码从受控库中检出(check out)，放入自己的开发库中进行修改；
     • (3) 程序员将开发库中修改好的代码检入(check in)受控库；
     • (4) 软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中。（更新版本号，旧版本不删除）

     

4. 配置状态报告

   • 每个受控配置项的标识和状态
   • 每个变更申请的状态和已批准修改的实施状态
   • 每个基线的当前和过去版本状态
   • 其他配置管理活动的记录

5. 配置审计

   • 配置审计：配置审核或配置评价，包括功能配置审计和物理配置审计。
     • 功能配置审计是审计配置项的一致性
     • 物理配置审计是审计配置项的完整性

6. 发布管理和交付

   • 发布管理和交付：存储、复制、打包、交付、重建
   • 文档管理、配置管理工具：SVN、CC、GIT

9. 各角色在配置管理活动中的权限