信息文档管理与配置管理

1.软件文档三类：

• 开发文档——开发过程本身
• 产品文档——开发过程的产物
• 管理文档——项目管理的信息

2.文档的质量可分为4级：

• 最低限度文档 1级文档——低于1个人月的开发者的自用程序
• 内部文档 2级文档——没有共享资源的专用程序
• 工作文档 3级文档——同一单位内若干人联合开发的程序
• 正式文档 4级文档——正式发行供普遍使用的软件产品

3.管理信息系统文档的规范化体现在4个方面：

• 文档书写规范
• 图表编号规则——

       eg：第1位-生命周期法各阶段；第2位-各阶段的文档；第3、4位-文档内容；第5/6位-流水码

• 文档目录编写标准
• 文档管理制度

4.配置管理

• 为了系统的控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科
• 6个活动：制定配置管理计划-配置标识-配置控制-配置状态报告-配置审计-发布管理和交付
• 在产品开发的生命周期中提供了结构化、有序化、产品化的管理方法，是项目管理的基础工作。
• 配置管理系统是整个项目管理信息系统的一个子系统；配置管理系统在大多数领域包括变更控制系统，是技术和行政指导与监督的一个正式的文档化程序的集合
• 配置管理所用的资源和工具要受项目的规模和财力限制，能够完成配置管理工作即可。手工方式是小型项目进行配置管理的重要工具之一。

 

5，配置项

在信息系统的开发流程中需加以控制的配置项可分为基线配置项和非基线配置项

基线配置项-所有的设计文档和源程序等

非基线——项目的各类计划和报告等

• 基线中的配置项被冻结，就不能再被任何人随意修改
• 一个产品可有一个/多个基线；一组配置项组成，；（产品的测试版本可以作为一个极限）
• 交付给 外部顾客的基线——发行基线；release 
• 内部开发的基线——构造基线；build

例子：区分设计阶段与开发阶段

设计阶段，每个配置项都要建立配置项；对逻辑上不同的产品分开做内部模块配置项并各自成立基线；并且相应的配置库必须分开，不能合并配置项；

开发阶段，从物理上讲，属于不同逻辑产品的模块代码是可以详谈的

6.configuration management officer CMO 配置管理员

所有配置项的操作权限应有CMO严格管理；负责在整个项目生命周期中进行配置管理活动

讲变更后的配置项纳入基线，并将变更内容和结果通知相关人

基本原则：

• 基线配置项——向开发人员开发读取权限（包括所有的设计文档和源程序等）
• 非基线配置项——向PM、CCB及相关人员开放（项目的各类计划和报告等）

基线定义：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限；（没有基线识别）

 

具体配置管理活动包括：

编写配置管理计划——建立和维护配置管理系统——建立和维护配置库——配置项识别——建立和管理基线——版本管理和配置控制——配置状态报告——配置审计——发布管理和交付——对项目成员进行配置管理培训

（创造基线/发行基线的步骤：

配置管理员识别配置项——为配置项分配标识——为项目创建配置库，并给每个项目成员分配权限——各项目团队成员根据自己的权限操作配置库——获得变更管理委员会（CCB）授权，创建基线或发行基线——形成文件——是基线可用等）

 

7.配置项状态：状态变化图

• 草稿——0.YZ(01-99)
• 正式——X.Y（X-主版号；Y-次版号；0-9）；第一次正式文件时，版本号1.0
• 修改——X.YZ（只改Z，成为正式时，Z归0）

注意：CCB同意变更，则配置项状态从“正式发布”—“正在修改”

8.配置库 configuration library——存放配置项并记录与配置项相关的所有信息

• 开发库development library——可任意修改

动态库/程序员库/工作库——保存开发人员当前正在开发的配置实体；需要保留各种信息

个人工作区，开发人员自行控制

• 受控库controlled libtrary——可修改，需走变更流程

主库——包含当前的基线加上对基线的变更；存放某阶段的成果；

库内信息的读写和修改都受限，受控库中的配置项被置于完全的配置管理之下

• 产品库 product libtrary——一般不再修改，修改走变更

静态库，发行库，软件仓库；包含已发布使用的各种基线的存档，形成最终产品，等待交付或现场安装；

库内信息完全受限，被置于完全的配置管理之下

（注：备份库——重要配置信息的备份，应急时恢复受损的配置库数据）

 

9.配置库的建库模式——2种

• 按配置项的类型分类建库——通用软件的开发配置；继承性强，工具同意，对并行开发有一定的需求。
• 按开发任务建立相应的配置库——适用于专业软件的开发组织；开发模式以线性为主；开发工具繁多，设置策略灵活

 

10.控制委员会CCB——configuration control board

• 负责对配置变更做出评估、审批及监督已批准变更的实施
• CCB不是常设机构，完全可以根据工作的需要组成，甚至可以是一个人或者兼职
• 属性有：名称、标识符、稳健状态、版本、作者、日期等

11.日常配置管理活动

（1）制定配置管理计划——由配置管理员CMO进行制定；CCB负责审批

（2）配置标识——功能和物理特征；是配置管理员的职能；

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

（3）配置控制——即配置项和基线的变更控制；

• 标识和记录变更申请
• 分析和评价变更

       变更评估的内容：变更对项目的影响；内容是否必要；范围是否考虑周全；实施方案是否可行；工作量估计是否合理；

• 批准或否决申请
• 实现、验证和发布已修改的配置项
• 

基于配置库的变更控制：

 

12.配置状态报告/配置状态统计 configuration status reporting

目的——及时给出配置项的当前状况，供相关人员了解，以加强配置管理工作

 

13.配置审计：configuration audit 配置审核/配置评价

• 包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性

     ①能配置审计 functional configuration audit——审计一致性；实际功效是否与其需求相一致

  （开发圆满，已达到配置标识中的性能和功能，操作和支持文档已完成并且合规）

     eg:代码走查

     ②理配置审计 physical configuration audit——审计配置项的完整性，物理存在是否与预期一致

 （要交付的配置项是否存在；是否包含了所有必需的项目）

    eg：变更过程的规范性审核、截止齐备性检查、配置项齐全性审核等

• 是为了确保项目配置管理的有效性，体现了配置管理的最根本要求——不允许出现任何混乱现象

14.

15.配置审核的作用：

16.P474

17.版本控制：

目的：按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆的现象，并且可以快速准确的到配置项的任何版本