一、信息系统文档
记住系统文档的两个重要特性：变更性和共享性。
二、配置管理的基本概念
1、配置项：是配置管理的对象，是一个独立存在的信息项。主要分为以下六种类型：
1）环境类：软件开发、运行和维护的环境，如编译器、操作系统、编辑软件、管理
系统、开发工具、测试工具等；
2）定义类：需求分析与系统定义阶段结束后得到的工件，如需求规格说明书、项目
开发计划、设计标准或准则、验收测试计划等；
3）设计类：设计阶段得到的工件，如系统设计说明书、数据库设计、用户界面设计
等；
4）编码类：编码及单元测试结束后得到的工件，如源代码、目标码、单元测试用例
等；
5）测试类：系统测试完成后得到的工件，如系统测试用例、测试结果、操作手册、
安装手册等；
6）维护类：维护阶段的工作，是以上任何需要变更的软件配置项。
2、配置管理
1）配置的定义：一个软件产品在生存期各个阶段的不同形式（记录和存储时所用媒
介）和不同版本的程序、文档和相关数据的集合。
2）配置管理的定义：
（1）是采用技术手段和行政手段进行管理和监督的一套规范化方法；
（2）对配置项的功能特性和物理特性加以标志，并将其文件化，并控制这些特性
的变更；
（3）报告变更进行的情况、变更实施的状态，以及验证与规定要求的一致性。
3、配置管理的意义：配置管理能够解决的问题：
1）多重维护问题：解决多个用户对同一文件进行修改所引起的版本不一致问题；
2）同时修改问题：解决多个用户对同一文件同时进行修改所引起的资源冲突问题；
3）丢失版本或不知版本问题：即要明确保留哪个版本，销毁哪个版本。
4、配置管理的主要任务：编制项目配置管理计划、配置标志、变更管理和配置控制、
配置状态说明、配置审核，以及进行版本管理和发行管理。
三、配置管理过程
1、配置管理中的角色和分工：
1）项目经理（PM，Project Manager）的职责：
（1）制定项目的组织结构及配置管理策略；
（2）批准、发布配置管理计划；
（3）决定项目起始基线和软件开发工作里程碑；
（4）接受并审阅配置控制委员会（CCB）的报告。
2）配置控制委员会（CCB，Configuration Control Board）的职责：
（1）批准配置项的标志、以及软件基线的建立；
（2）制定访问控制策略；
（3）建立、更改基线的设置，审核变更申请；
（4）根据配置管理员的报告决定相应的对策。
3）配置管理员（CMO，Configuration Management Officer）的职责：
（1）软件配置管理工具的日常管理与维护；
（2）提交配置管理计划；
（3）各配置项的管理与维护；
（4）执行版本控制和变更控制方案； （5）完成配置审计并提交报告； （6）对开发人员进行相关培训； （7）识别开发过程中存在的问题并制定解决方案。
4）开发人员（Dev，Developer）的职责：根据项目组织确定的配置管理计划和相关
规定，按照配置管理工具的使用模型来完成开发任务。
2、配置管理流程：
1）制定配置管理计划：由CMO完成，主要工作内容是制定配置管理策略、制定变
更控制策略、编写配置管理计划、评审配置管理计划；
2）创建配置管理环境：由CMO完成，主要工作内容是设置软硬件环境、建立配置
管理库、安装配置管理工具等；
3）配置管理计划的实施：由项目相关参与人员进行，主要包括配置标志、建立配置
基线、编制状态报告、执行配置审计和变更控制等；
4）配置管理计划的执行：主要分三个层面：
（1）由CMO完成日常管理和维护工作；
（2）由Dev具体执行配置管理策略；
（3）变更控制。
四、配置管理中的活动
1、配置标志：
1）定义：配置标志是配置管理的基础性工作，是进行配置管理的前提；配置标志是确定哪些内容应该进入配置管理形成配置项，并确定配置项如何命名，以及
用哪些信息来描述配置项。
2）配置项命名的两个要求：
（1）唯一性：在一个项目内不能出现重名现象，以避免混淆；
（2）可追溯性：名字应能体现相邻配置项之间的关系。
3）配置项的描述：
（1）名字：确切标志对象的字符串；
（2）描述：一个数据项表，包括用对象表示的配置项类型（如文档、程序或数
据），项目标志符，变更和版本信息；
（3）资源：该对象所提供的、处理的、引用的或另外所需要的实体；
（4）实现：基本对象是指向“文本单元”的指针，复合对象则为null。
2、版本控制：主要掌握版本标志的两种方法：
1）号码版本标志：
（1）处于“草稿”状态的配置项的版本号格式为：0.YZ；其中YZ的数字范围
为01~99；随着草稿的不断完善，YZ的取值应递增；YZ的初始值及增幅
由开发者自己把握；
（2）处于“正式发布”状态的配置项的版本号格式为：X.Y；X为主版本号，Y
为次版本号，取值范围均为1~9；配置项第一次“正式发布”时，版本号
为1.0；如果配置项的版本升级幅度较小，一般只增大Y值，X值保持不变；
只有当配置项版本升级幅度比较大时，才允许增大X值；
（3）处于“正在修改”状态的配置项的版本号格式为：X.YZ；当配置项在修改
时，一般只增大Z值，X.Y值保值不变；当配置项修改完毕，状态重新成
为“正式发布”时，将二值设置为0，增加X.Y值。
2）符号版本标志：该方法是将重要的版本属性有选择地给出，如windows98、
windows2003、Jbuilder2005等将版本产生的时间给出。
3、变更控制
1）注意：并不是所有的项目变更都需要走变更控制流程，在项目基准范围内的变
更可以直接实施，项目基准范围之外的变更必须走变更控制流程。
2）配置库的三种类型：
（1）开发库（动态库）：存放开发过程中需要保留的各种信息，供开发人员个人
专用；库中信息可做频繁修改，无需对库中信息做任何访问限制；
（2）受控库（主库）：在软件开发的某个阶段结束时，将工作产品或有关信息存
入，存入的信息包括计算机可读的程序代码，以及人工可读的文档资料，
应该对库内信息的读写和修改加以控制；
（3）产品库：在开发的软件产品完成系统测试之后，作为最终产品存入库内，
等待交付用户或现场安装，库内信息也应该加以控制。
3）配置基线：
（1）检查点、里程碑、基线的基本概念：
A、检查点：指在规定的时间间隔内对项目进行检查，比较实际与计划之间
的差异，并根据差异进行调整。可将检查点看作是一个固定“采样”时
点，而时间间隔可根据项目实际情况而定，频度过小会失去意义，频度
过大会增加管理成本。常见的间隔是每周一次，项目经理需要召开周例
会并上交周报。
B、里程碑：完成阶段性工作的标志，不同类型的项目里程碑不同。
C、基线：指一个（或一组）配置项在项目生命周期的不同时间点上通过正
式评审而进入正式受控的一种状态。基线其实是一些重要的里程碑，但
相关交付物要通过正式评审并作为后续工作的基准和出发点。基线一旦
建立后其变化需要受控制。
注：
A、 重要的检查点是里程碑，重要的需要客户确认的里程碑，就是基线。
在我们实际的项目中，周例会是检查点的表现形式，面向高层的阶段
汇报会是基线的表现形式。
B、 软件的一个测试版本可以作为项目的一个基线；
（2）基线的种类：
A、功能基线：被正式评审批准或签字同意的软件系统的规格说明；
B、分配基线：软件需求分析阶段结束时，经正式评审和批准的软件需求规
格说明；
C、产品基线：软件组装与系统测试阶段结束时，经正式评审和批准的有关
所开发的软件产品的全部配置项的规格说明。
（3）基线与配置项：基线可以由多个配置项组成，一个软件配置项可以是一个
文档，或者是一个可直接放在配置控制之下的工作产品，能够作为一个独
立的基本部件加以修改。
4）变更控制：着重掌握变更控制委员会（CCB）：
变更控制委员会又称配置控制委员会，是配置项变更的监管组织；其任务是对
建议的配置项变更做出评价、审批，以及监督已批准变更的实施；CCB的成员
通常包括项目经理、用户代表、软件质量控制人员、配置控制人员；该组织不
必是常设机构，完全可以根据工作的需要组成；小的软件项目CCB可以只有1
人甚至只是兼职人员。
4、配置状态报告：也称为配置状态说明与报告，它是配置管理的一个组成部分，其任
务是有效地记录报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。
5、配置审核：配置审核的工作主要集中在两个方面：
1）功能配置审核：即验证配置项的实际功效与软件需求是否一致；
2）物理配置审核：即验证配置项与描述它的技术性文档是否一致，重点在于验证
配置项的完整性，如：配置项包含的工作产品是否存在、配置项的标识是否正
确等。
注：配置审核的任务是验证配置项对配置标识的一致性；配置审核的实施是为了确
保项目配置管理的有效性，体现配置管理的最根本要求，不允许出现任何混乱
现象。