信息系统项目管理师考试辅导教程第3版第26章文档和配置管理.docx
《信息系统项目管理师考试辅导教程第3版第26章文档和配置管理.docx》由会员分享，可在线阅读，更多相关《信息系统项目管理师考试辅导教程第3版第26章文档和配置管理.docx（35页珍藏版）》请在冰豆网上搜索。
信息系统项目管理师考试辅导教程第3版第26章文档和配置管理
第26章文档和配置管理
26.1信息系统文档
每一个信息系统都会经历规划阶段、制订方案阶段、研制阶段、试运行阶段、安装
调试阶段、运行阶段和更新阶段，每一阶段都有大量的文档产生。
文档是记录系统的痕
迹，是系统维护人员的指南，是开发人员与用户交流的工具，是系统相关人员对系统了
解和使用的必须资料。
健全规范的文档意味着系统是按照工程化的方法开发的，意味着
系统的质量有了形式上的保证，而文档欠缺和文档的随意性和不规范性，极有可能导致
开发人员流动后，系统不可维护，成了没有生命力的系统。
信息系统的文档，不但包括软件开发过程中产生的文档，还包括硬件采购和网络
设计中形成的文档；不但包括上述有一定格式要求的规范文档，也包括系统建设过程
中的各种来往文件、会议纪要、会计单据等资料形成的不规范文档，后者是建设过程
中有各方谈判甚至索赔的重要依据；不但包括系统实施记录，也包括程序资料和培训
教程等。
26.1.1信息系统文档的种类
信息系统文档种类繁多，非常复杂，可以说是不胜枚举。
信息系统中的文档的作用
也就是系统中各种参与者之间交流沟通的工具。
下面我们从用户、分析人员、开发人员、
项目管理人员、测试人员、维护人员之间的交流沟通将这些文档做一个分类总结。
（1）用户和分析人员的沟通。
•可行性研究报告。
•总体规划报告。
•系统开发合同。
•系统方案说明书。
（2）开发人员与项目管理人员的沟通。
•系统开发计划（包括计划相关的各种文档）。
•系统开发月报。
•系统开发总结报告。
.536.信息系统项目管理师考试辅导教程（第3版）
•开发人员间的交流。
•系统方案说明书。
•系统设计说明书。
（3）测试人员和开发人员间的沟通。
•系统方案说明书。
•系统开发合同。
•系统设计说明书。
•测试计划。
•测试用例。
•测试记录。
•测试报告。
（4）系统开发人员和用户之间的沟通。
•用户手册。
•操作指南。
（5）系统开发人员和系统维护人员间的沟通。
≪系统设计说明书。
≫系统开发总结报告。
≪技术手册。
（6）用户与维护人员间的沟通。
，
•系统运行报告。
•维修修改建议。
26.1.2信息系统文档的特点
系统文档往往是多人合作完成的，并且会传送给更多的人使用。
它有两个重要的特
性：
变更性和共享性。
系统文档的形成并不是一蹴而就的，往往需要进行多次的修改，并且经常是在多人
之间的合作成果。
往往也需要经历开发、评审、修改的过程。
系统文档通常有众多的使
用者，文档开发者创建好文档后都需要经过一个有效的途径分发到使用者手上，通常是
每个使用者都有一份文档的备份。
如何在系统文档的开发过程中进行有效的控制和管理,如何进行文档的分发并保证
每个使用者都有相同的备份，这是文档管理中的一个重要课题，解决它的唯一办法就是
配置管理。
第26章文档和配置管理•537-
26.2配置管理的基本概念
26.2.1配置项
信息系统中的文档和软件在其开发、运行、维护的过程中会得到许多阶段性的成果,
并且每个文档、软件在开发和运行过程中还需要用到多种工具软件或配置。
所有这些信
息项都需要得到妥善的管理，决不能出现混乱，以便在提出某些特定的要求时，将它们
进行约定的组合来满足使用的目的。
这些信息项是配置管理的对象，称为配置项。
它们通常可以分成下面的6种类型。
（1）环境类。
软件开发、运行和维护的环境，如编译器、操作系统、编辑软件、
管理系统、开发工具、测试工具、项目管理工具、文档编制工具等。
（2）定义类。
需求分析与系统定义阶段结束后得到的工件，如需求规格说明书、
项目开发计划、设计标准或设计准则、验收测试计划等。
（3）设计类。
设计阶段得到的工件,如系统设计说明书、程序规格说明、数据库
设计、编码标准、用户界面设计、测试彳示准、系统测试计划、用户手册。
（4）编码类。
编码及单元测试结束后得到的工件，如源代码、目标码、单元测试
用例、数据及测试结果。
（5）测试类。
系统测试完成后的工作，如系统测试用例、测试结果、操作手册、
安装手册。
（6）维护类。
维护阶段产品的工作，以上任何需要变更的软件配置项。
配置项是一个独立存在的信息项，我们可以把它看成一个元素，单独的一个元素发
挥不了什么作用，但随着工作的进展，出于不同的要求，需要将这些元素进行不同的组
合，这个组合称配置，配置是一个软件产品在生存期各个阶段的不同形式（记录特定信
息的不同媒体）和不同版本的程序、文档及相关数据的集合，或者说是配置项的集合，
它具有完整的意义。
系统需求是由很多需求描述文件和系统用例组成的，每一个文件是一个配置项，所
有的配置项结合起来才能够形成一个完整的系统需求，系统需求就是一个配置。
26.2.2配置管理
简单来说，配置管理简单说，就是对配置的管理。
按国际标准IS09000:
3.1997的
说法，配置管理是一个管理学科，它对配置项（包括软件项）的开发和支持生存期给予
技术和管理上的指导。
配置管理的应用取决于:
^目的规模、复杂程序和风险大小。
软件
工程专家W.Babich认为，软件配置管理能协调软件开发，使得混乱减少到最小。
软件
配置管理是一种标志。
组织和控制修改的技术，目的是最有效地提高生产率。
《软件工
程术语》国家标准GB/T11457-1995,给配置管理下了定义，配置管理是标志和确定系
.538.信息系统项目管理师考试辅导教程（第3版）
统中配置项的过程，在系统整个生存期内控制这些配置项的投放和更动，记录并报告配
置的状态和变动要求，验证配置项的完整性和正确性。
并对下列工作进行技术和行动指
导与监督的一套规范：
（1）对配置项的功能特性和物理特性进行标志和文件编制工作。
（2）控制这些特性的变动情况。
（3）记录并报告这些变动进行的处理和实现的状态。
综合以上几种对配置管理的解释，可以把软件配置管理概括为：
它是采用技术手段
和行政手段进行管理和监督的一套规范化方法;对配置项的功能特性和物理特性加以标
志，并将其文件化；控制这些特性的变更；报告变更进行的情况和变更实施的状态及验
证与规定需求的f致性。
总之，配置管理主要是对软件生存期过程中的各种阶段产品和最终产品演化和变更
的管理，它是软件质量管理的重要组成部分。
如果从变更的意义讲，软件配置管理是要
解决软件的变更标志、变更控制，以及变更发布的问题。
26.2.3配置管理的意义
信息系统项目的对象是信息系统，它和传统的制造产品有着很大的差别，这些差别
决定了信息系统项目必须相应地采取特殊的措施，否则将无法达其目标。
信息系统是不
可见抽象的智力产品，其规模日益扩大和复杂，参加的人员数量日益增多，沟通工作量
也越来越大，并时时处于变化之中，并对系统开发人员的依赖相当大。
由于这些原因，
信息项目很容易造成信息的拥有者的版本不一致，或者需要的文件找不到，或者需求
变化太快以致产品与需求不一致的现象。
所有这些现象用配置管理的方法都是很容易实
现的。
具体的配置管理能够解决以下问题：
（1）多重维护问题。
一个文档的几个备份在不同的地方使用，或者若干个文档中
都含有一些共同的内容。
如果一个用户发现了一个文档出现了问题便直接进行修正，或
几个用户发现了问题都各自做了修正，这样，文档就不一致了。
’
这是配置管理最容易解决的问题，用户需要修改某文档时，必须从配置库中检出该
文档，修改后再检入，每个用户需要该文档时都从配置库中检出最新的文档。
（2）同时修改问题。
多个用户对同一个文档进行修改，这时就有可能出现有的用
户的变更消失了。
要解决这个问题，有两个办法，一个是同一时间只允许一个人检出，
另一个办法是将文档分成多个文档，避免编辑冲突。
（3）丢失版本或不知版本。
这个问题的解决要明确规定保留哪个版本，销毁哪个
版本；采用一种系统化的文档标志版本，并控制版本的变更采用统一的备份规程。
第26章文档和配置管理.539.
26.3配置管理过程
配置管理是CMM2中的一个重要的KPA，其作用就是建立和保证整个软件生命周
期中产品的完整性。
它是所有成熟的软件组织必需的一个管理过程。
本节说明配置管理
中的角色、流程及配置管理计划的制订。
26.3.1配置管理中的角色和分工
要使配置管理活动在信息系统的开发和维护中得到贯彻执行,首先要明确确定配置
管理活动的相关人员及其职责和权限。
配置管理过程的主要参与人员如下：
（1）项目经理（ProjectManager,PM）≫项目经理是整个信息系统开发和维护活
动的负责人，他根据配置控制委员会的建议，批准配置管理的各项活动并控制它们的进
程。
其具体工作职责如下：
•制订项目的组织结构和配置管理策略；
•批准、发布配置管理计划；
•决定项目起始基线和软件开发工作里程碑；
•接受并审阅配置控制委员会的报告。
（2）配置控制委员会（ConfigurationControlBoard,CCB）≫负责指导和控制配
置管理的各项具体活动的进行，为项目经理的决策提供建议。
其具体工作职责如下：
•批准配置项的标志，以及软件基线的建立；
•制订访问控制策略；
•建立、更改基线的设置，审核变更申请；
•根据配置管理员的报告决定相应的对策。
（3）配置管理员（ConfigurationManagementOfficer,CMO）≪根据配置管理计划
执行各项管理任务，定期向CCB提交报告，并列席CCB的例会，其具体工作职责如下：
•软件配置管理工具的日常管理与维护；
•提交配置管理计划；
•各配置项的管理与维护；
•执行版本控制和变更控制方案；
•完成配置审计并提交报告；
•对开发人员进行相关的培训；
•识别开发过程中存在的问题并制订解决方案。
（4）开发人员（Developer,Dev）。
开发人员的职责就是根据项目组织确定的配置
管理计划和相关规定，按照配置管理工具的使用模型来完成开发任务。
•540•信息系统项目管理师考试辅导教程（第3版）
26.3.2配置管理流程
配置管理流程图如图26-1所示。
1.制订配置管理计划
2.创建配置管理环境
3.*不/志
配置项
4.建立
基线
5.编制配置
状态报告
6.执行配
置审计
7.变更控
制管理
图26-1配置管理流程图
（1）制订配置管理计划。
在项目启动阶段，项目经理首先要制订整个项目的开发
计划，它是整个项目研发工作的基础。
总体研发计划完成之后，配置管理的活动就可以
展开了，如果不在项目开发之初制订配置管理计划，那么配置管理的许多关键活动就无
法及时有序地进行，而它的直接后果就是造成项目开发状况的混乱，并注定使配置管理
活动成为一种救火的行为。
由此可见，在项目启动阶段制订配置管理计划是项目成功的
重要保证。
配置管理计划由CMO制订，主要内容是制订配置管理策略，制订变更控制
策略，编写配置管理计划，评审配置管理计划。
（2）创建配置管理环境。
创建配置管理环境主要是由CMO设置硬件环境、设置网
络环境、设置软件环境、建立一个配置管理库，存储项目中定义的配置项，安装配置管
理工具，例如ClearCase,VSS等，并提供配置管理培训。
（3）配置管理计划的实施。
配置管理计划的实施由项目相关参与人员进行，主要
是进行配置标志、建立配置基线、编制状态报告、招待配置审计和变更控制。
制订配置管理计划的过程包括以下主要工作流程：
•CCB根据项目的开发计划确定各阶段里程碑和开发策略。
•CMO根据CCB的规划，制订详细的配置管理计划，交CCB审核。
•CCB审核通过配置管理计划后交项目经理批准，发布实施。
第26章文档和配置管理.541.
（4）配置管理计划的执行。
执行阶段的配置管理活动主要分为3个层面：
•由CMO完成日常管理和维护工作。
•由DEV具体执行配置管理策略。
•变更控制。
这3个层面彼此之间既相互独立、又互相联系。
在配置管理执行过程中，具体按照如下流程进行：
•CCB设定研发活动的初始基线。
•CMO根据软件配置管理规划设立配置库和工作空间，为执行配置管理人员做好
工作准备。
•开发人员按照统一的软件配置管理策略，根据获得授权的资源进行项目的研发
工作。
•CCB根据项目的进展情况，审核各种变更请求，并适时地划定新的基线，保证
开发和维护工作有序地进行。
26.3.3配置管理计划
原则上，配置管理计划是信息系统开发计划的一个组成部分。
一个信息系统项目启
动以后，要认真分析项目的要求和特点，精心地组织策划。
在考虑制订进度安排计划、
人员投入计划、质量保证计划、风险管理计划、文档编制计划等的同时，必须制订配置
管理计划。
配置管理计划通常要涉及该项目对配置管理的要求，实施配置管理的责任人、责任
组织及其职责，开展的配置管理活动、方法和工具等。
这里以IEEE的标准为例，介绍配置管理计划应包括的内容。
配置管理计划标准IEEE828-1990StandardforSoftwareConfigurationManagement
Plan。
Cl）引言。
•配置管理计划的目的、适用范围、使用要求。
•项目概述。
•项目中需特别关注的配置管理问题和风险。
•配置管理严格性要求的等级。
•限制和假设。
•术语。
•参考文件。
（2）配置管理。
•配置管理的组织结构。
•职责和权限。
•指令和方针。
.542.信息系统项目管理师考试辅导教程（第3版）
•参照的规程（组织的规程或客房的规程）。
•遵循的标准。
（3）配置管理活动。
•配置标志。
•变更管理和配置控制。
•配置状态说明。
•配置审核。
•接口和子合同方控制。
（4）配置管理进度安排。
•配置管理重要事件的顺序。
•配置管理各项活动间的依赖关系。
•与其他重要项目里程碑的关系。
（5）配置管理所需的资源。
•采用的工具。
•使用的设备。
•应用的技术。
•所需的培训。
•对其他人员的要求。
（6）配置管理计划的维护。
•维护的责任。
•计划更新的条件和审批。
•计划变更的交流和通报。
26.4配置管理中的活动
26.4.1配置标志
配置标志是配置管理的基础性工作，是管理配置管理的前提。
配置标志是确定哪
些内容应该进入配置管理形成配置项，并确定配置项如何命名，用哪些信息来描述该
配置项。
1.确定配置项
信息系统项目中形成的技术性文档和管理性文档，除一些临时性的文档外一般都应
该进行配置管理。
一般来讲，判定一个文档是否进行配置管理的标准应该是此文档是否
有多个人需要使用，这些文档往往在项目的进程中不断地修正和扩展，要保证每个使用
者都使用同一版本的文档，就必须将这些文档纳入配置管理，成为受控的配置项。
RogerS.Pressman认为至少以下所列的文档应该成为配置项。
第26章文档和配置管理.543.
（1）系统规格说明书。
（2）项目计划。
（3）需求规格说明书。
•图形分析模型。
•处理规格说明。
•原型。
•数学规格说明。
（4）用户手册。
（5）设计规格说明。
•数据设计描述。
•体系结构设计描述。
•模块设计描述。
•对象描述。
（6）源代码。
（7）测试规格说明。
•测试计划和步骤。
•测试用例、记录和结果。
（8）操作和安装手册。
（9）可执行程序。
•模块可执行代码。
•链接的模块。
（10）数据库描述。
•模式和文件结构。
•初始内容。
（11）联机用户手册。
（12）维护文档。
•软件问题报告。
•维护请求。
•工程变更指令。
（13）软件工程标准和规程。
2.配置项命名
确定了配置项后，还需要对配置项进行合理、科学的命名。
配置项的命名绝不能随
意为之，必须满足以下两点。
（1）唯一性：
要求在一个项目内不能出现重名现象，以避免混淆。
（2）可追溯性：
名字应能体现相邻配置项之间的关系。
一个典型的实例是采用层次式的命名规则来反映树状结构，树状结结构上结点之间
•544•信息系统项目管理师考试辅导教程（第3版）
存在着层次的继承关系。
如图26-2所示为一个典型的信息系统工程的配置项目录结构。
&S17
B-Merp
（-）-1.component
卜翻selfdeveloped
ftthirdpartycomponent
B-Rdoc
一龜analysisdoc
-1.designdoc
一fipmdoc
一動projectdefinition
——
l戀userguid
-1.env
B-fisrc
B-llcom
13-.mycom
S-filerp
team
卜Siteaml
L戀team2
S■麵tools
—1.compiletools
-.edittools
___________L麵packtools_____
图26-2—个典型的信息系统工程的配置项目录结构
3.配置项的描述
由于配置项除了名称外还有一些其他属性和与其他配置项的关系，因此它可以采用
描述对象的方式来进行描述。
每个配置项用一组特征信息（名字、描述、一组资源、实现）唯一地标志。
（1）名字：
确切标志对象的字符串。
（2）描述：
数据项表，应包括对象表示的配置项类型（如文档、程序或数据）、项
目标志符、变更和版本信息。
（3）资源：
该对象所提供的、处理的、引用的或另外所需要的实体。
例如，数据类
型、特定函数、甚至是变更名。
（4）实现：
基本对象是指向“文本单元”的指针；复合对象则为null。
配置项间的关系有整体和部分的关系及层次关系，也有关联关系。
配置项间的关系可以用MIL语言（ModuleInterconnectionLanguage）表不。
MIL
描述的是配置项间的相互依赖关系，可自动构造系统的任何版本。
26.4.2版本控制
1.什么是版本
对于信息产品的版本有两个方面的意思，一是为满足不同用户的不同使用要求，如
用于不同运行环境的系列产品。
如适合Linux、Windows、Solaris用户的软件产品分别
第26章文档和配置管理.545.
称为Linux版、Windows版和Solaris版。
它们在功能和性能上是相当的，原则上没有
差别，或者说，这些是并列的系列产品。
对于这类差别很小的不同版本，互相也称为变
体（Variant）。
另一种版本的含义是在软件产品投产使用后，产品经过一系列的变更，如纠错、增
加功能、提高性能的更改，而形成的一系列的顺序演化的产品，这些产品也称为一个版
本，每个版本都可说出它是从哪个版本导出的演化过程。
必须注意到，修正后的新版本往往不能完全代替老版本，尽管新版本有某些优越的
特性。
因为一些用户仍然使用着老版本，并且不容易立刻做到以旧换新，否则可能会打
扰老版本原有的工作环境。
显然，多个版本被多个用户同时使用的情况是不可避免的现
实。
这就要求多个版本共存，这也就是配置管理要解决的一个重要课题。
2.版本控制（VersionControl）
版本控制用于管理信息工程中生成的各种不同的配置将规程和相关管理工具结合
起来。
按GM.Clemm对版本管理的解释：
配置管理使用户借助选择适用的版本来选定
软件系统的配置，为此需要确定每个软件版本的属性，同时还考虑到同描述一些预期属
性所构成的配置。
版本管理要解决的第一个问题是版本标志，也就是为区分不同的版本，要给它们科
学的命名。
通常有以下几种版本命名的方法。
（1）号码版本标志。
以数字表示，如用1.0、2.0、1.2、2.1.1等表示版本号。
一般
认为1.0、2.0等为基础版本，1.1、1.2则是对基础版本1.0的第一次修改和第二次修改。
对有重大更动或因多次修改导致的全局性重要更动，则应该提高基础版本号，例如，上
升到2.0。
这种顺序号码的命名法被广泛地使用，它的突出优点就是简单直观。
但如果版本多
了，并且出现了非简单顺序的线型号码，就很难从号码上区分其前后的继承关系，无法
体现命名的可追溯性原则。
另外，只根据号码也不能看出更多的信息。
（2）符号版本标志。
这种标志版本的命名方法是将重要的版本属性有选择地给出，
如Windows98，Windows2000,JBuilder2005将版本产生的时间给出。
为了从版本标
志上看到更多信息，可能给出更多的属性，如面向的客户群、开发语言、硬件平台、生
成曰期等。
配置管理中，版本包括配置项的版本和配置的版本，这两种的版本的标志应该各有
特点，配置项的版本应该体现出其版本的继承关系，它主要是在开发人员内部进行区分。
另外，还需要对重要的版本做一些标记，如对纳入基线的配置项版本应该做一个标志。
对于配置来讲其版本号往往是在非常广的范围内使用，需要对其版本的重要属性进行标
志，但同时，它还必须有一个内部的版本号，这个内部的版本号通常采用的号码版本标
志方法。
上面讲的版本控制都是指配置管理的纵向生成的产品的版本控制，对于纵向的版本
即适应不同运行环境的版本，在配置管理中应该采用增加一个配置项或配置的方式来进
•546•信息系统项目管理师考试辅导教程（第3版）
行管理。
配置管理本身就应该将信息系统的生成产品纳入配置库，既然该信息系统生成
一系列应该用于不同环境的版本，当然每个版本都应该纳入配置管理，形成配置项。
26.4.3变更控制
配置管理的最重要的任务就是对变更加以控制和管理，其目的是对于复杂，无形的
软件，防止在多次变更下失控，出现混乱。
1.变更
（1）变更是不可避免的。
变更来源有两个方面，一是用户，他们是信息工程项目需求的提出者。
一个十分常
见的现象是用户提出需求以后，在开发过程中用户又改变了其需求，这只能迫使开发工
作返工，丢弃一些无法修正的部分。
无疑这会造成一定的损失，但却无法完全避免。
要
求用户一次性地把需求讲清楚，并且不允许此后做任何变更，这是不现实的。
我们只能
尽力减少变更，降低其影响。
开发人员如何解决好自己的工作产品与变更的用户需求之
间的一致性，正是CMM2级需求管理这个关键过程域的主要目标。
变更来源的另一个方面来自开发人员自身。
他们在工作中可能发现前期工作中有些
不妥当的地方，便要修改已经确定了的设计方案或是设计的细节。
也许是项目管理人员
提出要修订已经确定了的项目方案。
由此所导致的返工甚至部分工作产品的报废也是在
所难免的。
原则上说，随着工作的进展，无论是用户还是开发人员都将掌握更多的信息，对问
题本身和设计方案有了更深入的认识，同时也会发现原来的设想有不充分，不完善甚至
有不合理、不可行的成分。
这时提出
升级会员 