高项_第十四章信息文档管理与配置管理
第十四章信息文档管理与配置管理
软件文档分为三类
若管理文档中的3标注了开发文档，则属于开发文档里
若没有开发两字，则属于管理文档中
文档质量的四个等级
配置管理
什么是配置管理（了解）
配置管理的6个主要活动
配置项
配置项:项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据,它们经评审和检查通过后进入配置管理。
有些文档生成后不可修改的(如测量报告、会议纪要、工作报告) ,就不能当做配置项。配置项是可以修改的。
配置项可以分为基线配置项和非基线配置项两类
●基线配置项可能包括所有的设计文档和源程序等;
●非基线配置项可能包括项目的各类计划和报告等。
所有配置项的操作权限应由CMO (配置管理员)严格管理,基本原则是:基线配置项向开发人员开放读取的权限;非基线配置项向PM、CCB (控制变更委员会)及相关人员开放。
配置项的状态
配置项的状态可分为"草稿”“正式” 和“修改”三种。
- 配置项刚建立时,其状态为“草稿”。配置项通过评审后,其状态变为"正式”。
- 此后若更改配置项,则其状态变为”修改”。当配置项修改完毕并重新通过评审时,其状态又变为“正式”
配置项的版本号
( 1 )处于"草稿”状态的配置项的版本号格式为0.YZ , Yz的数字范围为01一99。随着草稿的修正, Yz的取值应递增。Yz的初值和增幅由用户自己把握。
(例如:0.1、0.5、0.99)
( 2 )处于“正式”状态的版本号格式为X.Y , x为主版本号,取值范围为1一9。Y为次版本号,取值范围为0一9。配置项第一次成为“正式”文件时,版本号为1.0。
(例如:1.1、1.5、2.3)
( 3 )处于“修改”状态的版本号格式为X.YZ。配置项正在修改时,一般只增大z值, X.Y值保持不变。当配置项修改完毕,状态成为“正式”时,将z值设置为0 ,增加X.Y值。
(例如:1.15、1.16)
配置项的版本管理
配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。在项目开发过程中,绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本”好”, 所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本,避免发生版本丢失或混淆等现象,并且可以快速准确地查找到配置项的任何版本。
配置基线（了解）
配置基线(常简称为基线)由-组配置项组成,这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了,不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。
一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。 产品的一个测试版本(可能包括需求分析说明书、概要设计说明书、详细设计说明书、己编译的可执行代码、测试大纲、测试用例、使用手册等)是基线的一个例子。
基线通常对应于开发过程中的里程碑( Milestone) ,一个产品可以有多个基线,也可以只有一个基线。交付给外部顾客的基线一般称为发行基线( Release) ,内部开发使用的基线一般称为构造基线 ( Build)。
配置库
配置库可以分开发库、受控库、产品库3种:
①开发库,也称为动态库、程序员库或工作库,用于保存开发人员当前正在开发的配置实体,动态库是开发人员的个人工作区,由开发人员自行控制。库中的信息可能有较为频繁的修改。( 可以任意的修改)
②受控库,也称为主库,包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。( 存放阶段性产物的，可以修改,需要走变，更流程)
③产品库,也称为静态库、发行库、软件仓库,包含已发布使用的各种基线的存档,被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后,作为最终产品存入产品库内,等待交付用户或现场安装。 (存放最终产品的, 一般不再修改,真要修改的话需要走变更流程)
了解
配置库的建库模式有两种：按配置类型建库和按任务建库
( 1 )按配置项的类型分类建库，适用于通用软件的开发组织。在这样的组织内,往往产品的继承性较强,工具比较统- - ,对并行开发有一定的需求使用这样的库结构有利于对配置项的统一管理和控制,同时也能提高编译和发布的效率。
( 2 )按开发任务建立相应的配置库,适用于专业软件的开发组织。在这样的组织内,使用的开发I具种类繁多,开发模式以线性发展为主,所以就没有必要把配置项严格地分类存储,人为增加目录的复杂性。对于研发性的软件组织来说,采用这种设置策略比较灵活。
配置库的权限设置（了解）
配置控制委员会 ( CCB )
配置控制委员会( CCB) ,负责对配置变更做出评估、审批以及监督已批准变更的实施。( CCB还有一个称呼变更控制委员会)
- 其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB不必是常设机构,完全可以根据工作的需要组成,例如按变更内容和变更请求的不同,组成不同的CCB。小的项目CCB可以只有一个人,甚至只是兼职人员。
- 通常，CCB不只是控制配置变更,而是负有更多的配置管理任务,例如:配置管理计划审批、基线设立审批、产品发布审批等。( CCB是决策机构,不是执行机构)
配置管理员（CMO）（了解）
制定配置管理计划（了解）
软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的
完整性。
配置管理计划由配置管理员制定，配置控制委员会负责审批。
配置管理计划的主要内容为:
①配置管理活动,覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付。
②实施这些活动的规范和流程。
③实施这些活动的进度安排。
④负责实施这些活动的人员或组织,以及他们和其他组织的关系。
1. 配置标识（了解）
2. 配置控制（了解）
3. 基于配置库的变更控制
现以某软件产品升级为例，简述其流程。
( 1 )将待升级的基线(假设版本号为V2.1 )从产品库中取出,放入受控库。
( 2 )程序员将欲修改的代码段从受控库中检出(cheek out) ,放入自己的开发库中进行修改。代码被Check out后即被"锁定”, 以保证同- -段代码只能同时被一个程序员修改,如果甲正对其修改，乙就无法Check out。
( 3 )程序员将开发库中修改好的代码段检入( Checkin )受控库。Cheek in后,代码的”锁定”被解除,其他程序员可以Check out该段代码了。
( 4 )软件产品的升级修改工作全部完成后,将受控库中的新基线存入产品库中(软件产品的版本号更新为V2.2，旧的V2.1版并不删除,继续在产品库中保存)。
4. 配置状态报告
- 每个受控配置项的标识和状态
- 每个变更申请的状态和已批准修改的实施状态
- 每个基线的当前和过去版本状态
- 其他配置管理活动的记录
5. 配置审计（了解）
配置审计也称配置审核或配置评价,包括功能配置审计和物理配置审计,分别用以验证当前配置项的一致性和完整性。
配置审计的作用: .
①防止向用户提交不适合的产品，如交付了用户手册的不正确版本。
②发现不完善的实现,如开发出不符合初始规格说明或未按变更请求实施变更。
③找出各配置项间不匹配或不相容的现象
④确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。
⑤确认记录和文档保持着可追溯性。
功能配置审计是审计配置项的一致性(配置项的实际功效是否与其需求一致)
物理配置审计是审计配置项的完整性(配置项的物理存在是否与预期一致)
6. 发布管理和交付（了解）
发布管理和交付:①存储②复制③打包④交付⑤重建
文档管理、配置管理I具:SVN、CC、GIT。
各角色在配置活动中的权限
