【第14章】文档和配置管理
1 章节相关
1.1 考试相关
一般上午一般考1-2分
案例分析20下、21下刚考
2 信息系统项目文档及其管理
2.1 软件文档分类
| 类型 | 作用 | 文档种类 |
|---|---|---|
| 开发文档 | 描述开发过程本身 |
可行性研究报告和项目任务书；需求规格说明；功能规格说明；设计规格说明，包括程序和数据规格说明；开发计划；软件集成和测试计划；质量保证计划；安全和测试信息 |
| 产品文档 | 描述开发过程的产物 |
培训手册；参考手册和用户指南；软件支持手册；产品手册和信息广告 |
| 管理文档 | 记录项目管理的信息 |
开发过程每个阶段的进度和进度变更的记录；软件变更情况的记录；开发团队的职责定义；项目计划、项目阶段报告;配置管理计划 |
2.2 文档质量分级
| 文档的分级 | 适用范围 |
|---|---|
| 最低限度文档（1级） | 适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介 |
| 内部文档（2级） | 可用于没有与其他用户共享资源的专用程序【无共享资源】2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序 |
| 工作文档（3级） | 适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。 |
| 正式文档（4级 | 适合那些要正式发行供普遍使用的软件产品 |
2.3 文档规范管理
★3、文档的规范化管理：①文档书写规范、②图表编号规则、③文档目录编写标准、④文档管理制度
（1）文档书写规范：应该遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、
注明文档书写人及书写日期等；
（2）图表编号规则：对这些图表进行有规则的编号，可以方便图表的查找；
（3）文档目录编写标准；
（4）文档管理制度：应该建立相应的文档管理制度
3 配置管理
配置管理越早规划越好!
例子一∶没有配置及变更管理的研发文档会不一致(大家拿到的文档不一致)
例子二:没有配置及变更管理的代码可能会混乱不堪（多人维护同一段代码错乱)
★1、配置管理包括6个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、
配置审计、发布管理和交付。★2、典型配置项包括：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据★3、在信息系统的开发流程中需加以控制的配置项可以分为基线配置项和非基线配置项两类
基线配置项可能包括所有的设计文档和源程序等；
非基线配置项可能包括项目的各类计划和报告等。
所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。
| 基线类型 | 基线包括 | 管理原则 |
|---|---|---|
| 基线配置项 | 所有的设计文档和源程序 | 向开发人员开放读取的权限 |
| 非基线配置项 | 项目的各类计划和报告 | 向PM、CCB及相关人员开放 |
| 说明 | 所有配置项的操作权限应由CMO（配置管理员）严格管理 |
3.1 配置项状态
★4、配置项的状态：草稿、正式、修改三种。
配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。
此后若更改配置项，则其状态变为“修改”。
当配置项修改完毕并重新通过评审时，其状态又变为“正式”。
3.2 配置项的版本号
①处于“草稿”状态的版本号格式为0.YZ，YZ的数字范围为01～99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握(例如∶0.1、0.5、0.99 )
②处于“正式”状态的版本号格式为X.Y，X为主版本号，取值范围为1～9。Y为次版本号，取值范围为0～9。配置项第一次成为“正式”文件时，版本号为1.0。(例如∶1.1、1.5、2.3 )
③处于“修改”状态的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。(例如∶1.15、1.16 )
★6、配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
7、配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。★8、一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、己编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子。★9、基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。
◆ 交付给外部顾客的基线：发行基线（Release）
◆ 交付给内部开发使用的基线：构造基线（Build）★10、每一个基线，定义的内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。对这些基线的更新只能采用正式的变更控制程序。
3.3 开发库、受控库、产品库
| 配置库 | 解释说明 | 修改原则 |
|---|---|---|
| 开发库 | 也称动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，动态库是开发人员的个人工作区，由开发人员自行控制。库中的`信息可能有较为频繁的修改 |
可以任意的修改` |
| 受控库 | 也称主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库
|
可以修改，需要走变更流程 |
| 产品库 | 也称静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装
|
一般不再修改，真要修改的话需要走变更流程 |
3.4 配置库的建库模式
配置库的建库模式有两种：按配置项类型建库和按任务建库.
| 建库方法 | 适用范围 | 优缺点 |
|---|---|---|
| 配置项的类型 |
通用软件的开发组织 |
产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率 |
| 开发任务 |
专业软件的开发组织 |
使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活 |
| 说明 | ◆ 用于建立配置库的工具：VSS、CVS；也可以通过手工方式进行建库 |
|
| 配置库 |  |
3.5 权限配置
配置库的权限设置主要是解决:库内存放的配置项什么人可以“看”、什么人可以“取”、什么人可以“改”、什么人可以“销毁”等问题。配置管理员负责为每个项目成员分配对配置库的操作权限
配置库权限设置
受控库权限设置
产品库权限配置
练习题 【实战演练-21下案例】
通常来说，质量管理人员不应具备（）的权限。
A.产品库代码的Check权限
B.产品库文档的Check权限
C.受控库代码的Check权限
D.受控库文档的Check权限
3.6 配置控制委员会、配置管理员
★14、配置控制委员会（CCB）,负责对配置变更做出评估、审批以及监督已批准变更的实施。
其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的CCB。小的项目CCB可以只有一个人，甚至只是兼职人员。
通常，CCB不只是控制配置变更，而是负有更多的配置管理任务，例如：配置管理计划审批、基线设立审批、产品发布审批等。
15、配置管理员负责在整个项目生命周期中进行配置管理活动，具体有：①编写配置管理计划、②建立和维护配置管理系统、③建立和维护配置库、④配置项识别、⑤建立和管理基线、⑥版本管理和配置控制、⑦配置状态报告、⑧配置审计、⑨发布管理和交付、⑩对项目成员进行配置管理培训。
16、软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。
17、软件配置的整体性在整个项目生命周期中得到控制。软件质量保证人员应该定期审核各类软件基准以及软件配置管理工作。使软件基准的状态和内容能够及时通知给相关组别和个人★18、配置管理计划由配置管理员制定，配置控制委员会负责审批。
19、配置管理计划的主要内容为：
①配置管理活动，包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付。
②实施这些活动的规范和流程。
③实施这些活动的进度安排。
④负责实施这些活动的人员或组织，以及他们和其他组织的关系。★20、配置标识是配置管理员的职能，基本步骤如下：
①识别需要受控的配置项。
②为每个配置项指定唯一性的标识号。
③定义每个配置项的重要特征。
④确定每个配置项的所有者及其责任。
⑤确定配置项进入配置管理的时间和条件。
⑥建立和控制基线。
⑦维护文档和组件的修订与产品版本之间的关系。★21、配置控制即配置项和基线的变更控制，包括下述任务：标识和记录变更申请，分析和评价变更，批准或否决申请，实现、验证和发布已修改的配置项。
变更流程：①变更申请、②变更评估、③通告评估结果、④变更实施、⑤变更验证与确认、⑥变更的发布、⑦基于配置库的变更控制
CCB负责组织对变更申请进行评估并确定以下内容：①变更对项目的影响、②变更的内容是否必要、③变更的范围是否考虑周全、④变更的实施方案是否可行、⑤变更工作量估计是否合理。
3.7 软件产品升级流程
①将待升级的基线（假设版本号为V2.1）从产品库中取出，放入受控库。
②程序员将欲修改的代码段从受控库中检出（Checkout），放入自己的开发库中进行修改。代码
被Checkout后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check out。
③程序员将开发库中修改好的代码段检入（Check in）受控库。Check in后，代码 的“锁定”被解除，其他程序员可以Check out该段代码了。
④软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品的版本号更新为V2.2,旧的V2.1版并不删除，继续在产品库中保存）。
★23、配置状态报告的内容：
①每个受控配置项的标识和状态
②每个变更申请的状态和已批准的修改的实施状态。
③每个基线的当前和过去版本的状态以及各版本的比较。
④其他配置管理过程活动的记录。
3.8 配置审计
24、配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当
前配置项的一致性和完整性。
★25、配置审计的作用：
①防止向用户提交不适合的产品，如交付了用户手册的不正确版本。
②发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。
③找出各配置项间不匹配或不相容的现象。
④确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。
⑤确认记录和文档保持着可追溯性。
★26、功能配置审计是审计配置项的一致性（配置项的实际功效是否与其需求一致），验证：
①配置项的开发已圆满完成。
②配置项已达到配置标识中规定的性能和功能特征。
③配置项的操作和支持文档己完成并且是符合要求的。
★27、物理配置审计是审计配置项的完整性（配置项的物理存在是否与预期一致），验证：
①要交付的配置项是否存在。
②配置项中是否包含了所有必需的项目。
28、发布管理和交付：①存储、②复制、③打包、④交付、⑤重建
3.9 文档管理、配置管理工具：
1、常用付费软件配置管理工具有：
①RationalClearCase、②Perforce、③CACCC、④HavestMerantPVCS、⑤MicrosoftVSS,CVS
2、常用的开源免费的软件配置管理工具有:①SVN、②GIT、③CVS
3.10 发布管理与交付
4 练习题
【例1-16上】基线是项目配置管理的基础。（）不属于基线定义中的内容。
A.建立基线的事件 B.基线识别 C.受控的项 D.批准基线变更的权限【例2-16上】在项目配置项中有基线配置项和非基线配置项，（）一般属于非基线配置项。
A.详细设计 B.概要设计 C.进度计划 D.源代码【例3-16上】某软件项目的《需求规格说明书》第一次正式发布时，版本号为V1.0，此后，由于发现了几处错误，对该《需求规格说明书》进行了2次小的升级，此时版本号应为（）。
A.V1.11 B.V1.2 C.V2.0 D.V2.1【例4-16上】配置项的状态有三种：草稿、正式发布和正在修改。以下叙述中，不正确的是（）。
A.配置项刚建立时状态为“草稿”，通过评审后，状态变为“正式发布”
B.配置项的状态变为“正式发布”后，若需要修改必须依照变更控制流程进行
C.已发布的配置项通过了伽的审批同意更改，此时其状态变为“正在修改”
D.通过了变更控制流程审批的配置项，修改完成后即可发布，其状态再次变为“正式发布”【例5-16下】某项目范围基准发生变化，经（62）同意，对需求规格说明书进行变更，则该配置项的状态应从（63）。
（62）A.项目经理 B.技术负责人 C.配置管理员 D.变更控制委员会
（63）A.“草稿”变迁为“正在修改” B.“正式发布”变迁为“正在修改”
C.“Checkin"变迁为“Checkout” D.“Checkout”变迁为“Checkin”【例6-17下】某软件企业为了及时、准确地获得某软解产品配置项的当前状态，了解软件开发活动的进展状况，要求项目组出具配置状态报告，该报告内容应包括（）。
①各变更请求概要：变更请求号、申请日期、申请人、状态、发布版本、变更结束日期
②基线库状态：库标识、至某日预计库内配置项数、实际配置项数、与前版本差异描述
③发布信息：发布版本、计划发布时间、实际发布时间、说明
④备份信息：备份日期、介质、备份存放位置
⑤配置管理工具状态
⑥设备故障信息：故障编号、设备编号、申请日期、申请人、故障描述、状态。
A.①②③⑤ B.②③④⑥ C.①②③④ D.②③④⑤【例7-17上】以下关于软件版本控制的叙述中，正确的是（）。
A.软件开发人员对源文件的修改在配置库中进行
B.受控库用于管理当前基线和控制基线的变更
C.版本管理与发布由CCB执行
D.软件版本升级后，新基线存入产品库且版本号更新，旧版本可删除【例8-18上】某软件开发项目在测试时发现需求需要调整，涉及到需求规格说明书、概要设计、详细设计及代码等相关文档的变更，需要对（）进行变更控制。
A.知识库 B.配置库 C.产品库 D.数据库【例9-18下】关于软件配置管理的描述，不正确的是（）。
A.配置控制委员会成员必须是专职人员
B.配置库包括动态库（开发库）、受控库（主库）、静态库（产品库）
C.常用的配置管理工具有AVN、GIT等
D.配置项的状态分为草稿、正式和修改三种【例10-18下】在项目配置项与基线的变更控制中，（）是配置管理员们主要工作。
A.确定受变更影响的关联配置项和有关基线
B.将变更申请的决议通知受此变更影响的每个干系人
C.组织修改配置项，并在相应的文档或程序代码中记录变更信息
D.将变更后的配置项纳入基线，并将变更内容和结果通知相关人【例11-19上】配置管理工作中，确定配置项的所有者及其责任、确定配置项进入配置管理的时间和条件是（）的工作内容。
A.配置状态报告 B.配置审计 C.配置控制 D.配置标识【例12-19上】关于配置控制委员会（CCB）的说法，正确的是（）。
A.CCB负责分配配置库的操作权限
B.CCB负责制定配置管理计划
C.CCB必须是常设机构
D.CCB可以是兼职人员【例13-20下】关于配置管理的描述,正确的是（）。
A.某个配置项的版本号为0.91,该配置项的状态为“正式”
B.配置版本管理的目的是保留配置项的最新版本,删除所有旧的版本,以避免发生版本混淆
C.一个产品只能有一个基线,因此对基线的变更必须遵循正式的变更控制程序
D.开发库中的信息可能被频繁修改,因此可以由开发人员自行控制【例14-20下】配置管理员的工作职责不包括（）。
A.基线设立审批 B.版本管理和配置控制 C.建立和维护配置库 D.配置状态报告【例15-21上】某软件产品集成测试阶段，发现问题需要对源代码进行修改，此时，程序员将待修改的代码段从（）检出，放入自己的（）中进行修改，代码即被质定保证同一段代码只能被一个程序员修改。
A.产品库、开发库 B.受控库、开发库 C.产品库、受控库 D.受控库、产品库【例16-21下】A、B两个开发人员对信息系统的同一软件部件的两个bug（位于同一代码段）进行修改，当B欲把计划修改的代码段从（）检出时，显示锁定，基于配置库的变更控制，可知此时该代码段正在工程师A的（）中进行修改。
A.开发库、受控库 B.受控库、开发库 C.受控库、产品库 D.产品库、开发库【例17-22上】在配置控制中，（）不属于CCB变更。
A.变更实施方案可行性 B.变更工作量的合理性 C.变更对项目的影响 D.记录变更信息的准确性
参考答案
