软件项目的配置管理全

，第八章软件项目的配置管理

第八章•目录

8.1软件配置及其管理的概念

8.2配置管理活动和流程

8.3配置管理需求

8.4版本管理

8.5变更管理

8.6配置状态监测与报告

8.7基于配置管理的软件项目管理

8.8配置管理的技术手段和工具

第八章•目录

|口［=>

8.2配置管理活动和流程

8.3配置管理需求

8.4版本管理

8.5变更管理

8.6配置状态监测与报告

8.7基于配置管理的软件项目管理

8.8配置管理的技术手段和工具

8.1软件配置及其管理的概念

8.1.1CMM2的配置管理概念

8.1.2IEEE的配置管理定义

8.1.3配置管理概述

8.1.4配置管理活动的作用

2010-4-64

-e—,--=J』

四巳y上

J配置的才白硬件

星师是如何处理接口的?

J轨件工，

J

匡i软件的变化可以发生在一秒钟内

1•软件的变化可以发生在每一秒钟

一•软件开发过程下一秒钟是不确定的

•情况将会怎样？怎么办?

2010-4-65

焉

/伤

刁

彳

了

事

写快史。/闩一八名伙石土你的演示，认为很有市场潜

力

，合迸公司正在给某行业用户正在准备开发的系统中，成为

蒐

该像心技术或一个别人没有的卖点。

下-（你的老板准备就此豪赌一把了），与你

"国

不同的是，公司从其他部门为你配备了系统分析师，还

_希.编制员、测试员。你的核心模块已经被大量的用户功能所包

空成为一个行业应用系统，并开始给用户试用，这是你的系统的第

个月后，公司决定把系统升级到第二版，除增加了许多新的功能

三二二科，公司决定支持多平台，同时，为了提高系统的性能和效率，准备

一采用第三方厂家的中间件，取代自己做的接口。第一版的缺陷修改，

=:-也要反映到第二版中。

/第2版经过2个多月的开发，最终推向了市场。公司的这个产品不但被

用户所欢迎，也被一家大公司所看中（就像IBM收购了Lotus和

RationaleInformix一样），你们的产品，正好可以填补这家大公司

产品线的空缺，你所在的公司被这家公司买去了。

2010-4-66

一,一’—产品经理、项目经理。-——•''''，f.z、-

测试期团总部独立的测R部™门承V担。-T定把项目组增

加到殛在你所在的城市。在新公司里，产品管

理靖项wii的/防法

jZirczz^rr心

利不同的吟是—『THJ子住行开发目勺

乙瘴上去是一家出来的不同的兄弟和姐妹。

a%

与软件■版、第2版相比，你的项目管理有什么不同?

觉个产品的演变，项目发生了四个变化:

素统的复杂性发生了很大变化；

A.直芯用于开发该系统的项目环境发生了很大变化;

(④-在不同的项目生命周期内，项目控制本身的要求和力度发生了很

一大变化；

(4)由于组织的变化，管理流程、人员、方式发生了很大变化。

前二类变化要求项目的组织和管理适应系统扩展的需要，后二种变

化则要求项目管理具有适应性和灵活性。

2010-4-67

，发人员之间缺乏必要的交流

产■和维护所必需的程序和文档非常混乱

装过程中的人员流动经常发生

二管理不善致使未经测试的软件加入到产品中

•-项目开发状态不清楚

•软件生产达不到规模化

2010-4-68

匚UA/匕丐国觞跖

IB

序演变的学科，它作为软件工程的关键元素，

窥件开发和维护的重要组成部分……

贿结构化的，有序化的，产品化的管理软件工

.寝。它涵盖了软件生命周期的所有领域并影响所

据和过程。

-•配置管理是指用于控制系统一系列变化的学科。

-•通过一系列技术，方法和手段来维护产品的历史，鉴

别和定位产品独有的版本，并在产品的开发和发布阶段

控制变化。

•通过有序管理和减少重复性工作，配置管理保证了生

产的质量和效率。

2010-4-69

I变更是不可避免的，而变更加剧了工］

件开发者之间I标就是

群向其他有关人麻告变更。

嬴识「组织和控制修改的技术，目的是

因此■峥康讲，SCM1

使错误降为生产

1下方法，强化软件的可靠性和质量:

于识别和控制文档、代码、接口、数据库的结构框架，适用于

软件开蒙懒期的所有阶段;

电攀某一特定开发及维护工作方法,能够适应各种类型的需求、

藻、组织机构以及相关的管理策略；

新特定的基线状态、变更控制、测试、发布版本或审查活动，生成

息和产品信息。

，穹昉从某种意义上讲，SCM本质上是变更的管理。

一二S皿使软件产品和过程的变更变为受控的和可预见的，它要求并在适当的

二工具支持下能够做到这样几点：

(1)谁做的变更？

(2)软件有什么变更？

(3)什么时间做的变更?

(4)为何要变更？

2010-4-610

随着计;L软件的发展，软件开发已由最初的“程序设计阶段”

经历喜软件系统阶段”进而演变为后来的“软件工程阶段"，软

件的复雪性日益增大。此时，如果仍然把软件看成一个单一的

抚法解决所面临的问题，于是配置的概念逐渐引入软

人们越来越重视软件配置的管理工作。

JJ不懂软件项目的IE置管理，就不懂软件开发管理

J不对软件项目进亍配置管理，就没有进行软件项目开

发管蟠

2010-4-611

霎■对软件产品配置的标志和识别

’■系统地控制对处于配置管理下的各种软

件制品的修改和更新

三二■维护软件开发过程中的各种制品的一致

性和可跟踪性

2010-4-6

//目标1：

口二打）.再线两松昌国事（用5,

✓✓Q/brc/,匕二一卜卜/vy

/1—1qzj'G.好/—l川一松JI

“目标3:对于处于配置管理下的软件制品的修改被控制

，7目标4:与城轨件制品相关的项目组和成员应该被通知制品的目前

N和被修改的信息

朝目的的定义可以看出，CMM2的配置管理应包括这样一些

手定时间点的软件配置（即所选择的工作产品及其描

满）系统地控制这些配置的更改，并在软件生命周期中保持这

的完整性和可跟踪性。

-CMM2认为，受控于配置管理的工作产品，包括交付给用户的软

件产品（如：代码等），以及生成软件产品所需要的有关项

「（如：项目管理文件）。

CMM2的配置管理活动最主要的内容是：建立软件基线库，该库

存储开发的软件基线。通过软件配置管理的更改控制和配置审核

功能，系统地控制基线变更和由软件基线库生成的软件产品版

0莪。13

201

SCM要求月

软件配置管理委员会；

21Mj和实现软件配置管理的组织已经建立;

箪软件配置管理所需要的各项资源已经分配;

配置管理组织里的成员已经接受了软件配置目

尿、流程、方法方面的培训;

51软件项目组或是其他的相关的部门经过培训，可以

执行他们的软件配置管理活动;

2010-4-614

档化的流程，项目软件配置管理计划已准备

暑假的已获批准的软件配置管理计划可用作以后

靠己置管理活动的基础；

装软件配置管理库已经创建，并可用作进入基线的软

军学件制品的存贮库；

-4.处于软件配置管理下的软件制品被标志和识别；

5.对于配置项的变更请求和问题报告被初始化、计

戈k评审、批准并根据文化化的流程对其进行跟

际□e?；

2010-4-615

发布的产品必须从软件配置库中取出，并且产品发

布的流程须依照文档化的流程和规定；

^^8.根据文档化的流程和规定，软件配置项的状态被记

曲宗；

1^二==9：记录软件配置管理活动和软件基线内容的报告被建

三立；并通知受到影响的项目组和个人；

10.根据文档化的流程进行软件制品基线的评审；

2010-4-616

MM.目配置经理(ProjectConfiguration

Manager)与软件百己置管理计划

，变更控制委员会(ChangeControlBoard)

_组织级配置管理

■组织配置管理库(Organizational-

二二二ConfigurationManagementCell)

-1.负责项目完成后的软件配置管理活动

■二一2.管理组织级的文档

2010-4-617

的配置管理定义

工EEE标准％29T983就配置管理的内:容进行了规范的定义：

运加卢晶的结松性及其类型，为其分配唯言的一

标明符，并凿窗/形药提供三阴ra荐必广

r2；控制：,鼬■磔二靠前替蹄蜃线窿「■控缩南制］版软修件通产喻晶旗的发布和在整个软件生

命周期中对翦件产品的修改。例如，它将解决哪些修改会在该产品的

最新版本中巍A;现的问题。

C3J状态纪记录并报告构件和修改请求的状态，并收集关于产品

构件的重勇。计信息。例如，它将解决修改这个错误会影响多少个文

件.....

（4）审计利审查：确认产品的完整性并维护构件间的一致性，即确保

零个严格定义的构件集合。例如，它将解决目前发布的产品所

阐I建:件的版本是否正确的问题。

器对产品的生产进行优化管理。它将解决最新发布的产品应

一由嘛些版本的文件和工具来生成的问题。

（6）确保软件组织的规程、方针和软件周期得以正确贯彻

执行。它将解决要交付给用户的产品是否经过测试和质量检查的问

题。

（7）绢协作：控制开发统一产品的多个开发人员之间的协作。例

如，它将解决是否所有本地程序员所做的修改都已被加入到新版本的

26t晶-史的问题。18

,识

独立部件一韭嗔a勿厢网Mj整ililLJSagi遇励⑦EaEwiFH叼伫工曾牟

命周期匚摩1蒙客瑞罪提供对软件过程及其软件产品的跟踪

能力。它回冬什么是受控的?

配置变更控制3括在软件生命周期中控制软件产品的发布和变

一薪确保软件产品质量的机制。它回答：受控产品怎

箍控制变更？何时接受，恢复，验证变更？

上一卜括记录和报告变更过程，目标是不间断记录所有

的状态和历史，并进行维护，它解决以下问题：系统已经

三二很子什么变更？此问题将会对多少个文件产生影响？配置变更控

一—帝诞针对软件产品，状态统计针对软件过程。因此，二者的统一

一二就是对软件开发（产品、过程）的变更控制。

修将验证软件产品的构造是否符合需求、标准、或合同的

要求，目的是根据SCM的过程和程序，验证所有的软件产品已

经产生并有正确标识和描述，所有的变更需求都已解决。它回

答：系统和需求是否吻合？是否所有变更都是在版本控制下？

2010-4-620

由W不研层次

SCM从应用正司史"

为中心

版本控制空缨应用于个人独立开发或小组开发，它可以控制任何

文件的姓百一实现分支和归并功能、进行文本比较、标记注释和

版本报告彳主要工具有MS的VisualSourceSafe及Intersolv

PVCX

以开发者为中心主要应用于部门级开发，它可用于软件维护、不

四彳:加工厂

M尸时ff的开发任务、并行开发、QA及测试，它面向大型团队、利

考至交流、能最大限度地利用人力资源，主要工具为Rational

忑演rCase及MKSSourceIntegrity。

程驱N主要使用于企业级开发，着重解决新的工具引入、IT审

核、管理报告、复杂的生命周期、应用工具包、集成解决方案、

资料库等问题，实现真正规范的团队开发，主要工具为Platinum

TechnologyCCC/Harvesto

2010-4-621

商ifigu6而^写配置项（Configuration

件开发过程中生成各种制品的总和叫做这个

杭州的软件配置[RogerS.Pressman,1997]

二一三.■计算机程序，包括源代码和可执行程序

~一一-一_

R三三■与计算机程序相对应的各种文档

■计算机数据，包括计算机程序中包含的数据和

系统初始化数据

2010-4-622

。基线

」项目殂道过程的制品经过正式评审并被相关人员

i同意，可以作为以后项目开发的基础。对已

定为基线的制品的修改必须要通过正式的变

二_一一-1

一■在软件工程环境中，基线是指在软件开发过程中

「的里程碑，这些里程碑的标志是一项或多项经过

正式的技术评审并一致认同的软件制品的提交。

2010-4-623

建立和访问软件制品库，这个制品库主

饕用来对保存配置项和一些与软件配置管理

■1关的记录。

£■目前比较好的配置管理工具：Clearcase

一二(Rational),Notes/Domino(Lotus),PVCS

(Merant)andVSS(Microsoft).

2010-4-624

配置管理库⑴

ProjectRoot

Directory

Code

DOC

ProjectRequirementsDesignCode,UnitSystemTestDATA

PlanningAnalysisPhaseTest&Phase

PhasePhaseDocumentsIntegrationDocuments

DccurpentsDocumentsPhase

Documents

B回

PhasePhaseProductTest

DeliverablesDeliverablesSoftwareSoftware

ProductTest

SourceObjectiveExecutive

SoftwareSoftware

CodeCodeCode

2010-4-6Related-Related25

配置管理库

-n-----r

配目

♦口文件件是项目开发过程中由项目组创

，■J-

-151-»一r日维护的制品归档库。■

「软件配置管理负责管理和控制项目文件

-—.一一，夹，并对文件夹中的内容进行评审;

二二一，项目经理负责监督项目的软件配置管理

一」执行；

•软件质量工程师负责对项目文件夹的内

容进行评审；

2010-4-626

［日文个

F项目开发过程中的所有信息，包括文

料、工作制品和各种周报、月报、评

■审等；

些与外部的交流信息，例如与客户、第

三三_三方的通讯交流记录等；

三•其他交流会议记录，例如：重要的

Email,传真，信件等；

2010-4-627

权限管理

■项目组内部的权限管理与分配

■对其他项目组的开放权限管理与分配

■对其他用户或是第三方的权限管理与

分配

2010-4-628

I-■-!!j

■U~~•!

LL।—•>_；、

P=!_1—J

:薛系的诸多支持活动中，配置管理处在支持

宿lib位置。质量管理虽然也有过程的验证，

配置管理只要定义的配置项够细，则它可以管理

t件开发的全过程，细到每一个模块、每一个文|

档、每一条工程记录的变化。

等二亩此，配置管理从基础层开始，有机地把其它支持

活动结合起来，形成一个整体，相互促进，相互影

响，有力地保证了质量体系的实施。

2010-4-629

缩出速二周期

减工-1-*费7^,用nil

（2）有不H于知识库的建立

对象库

图务及经验库

尊）规范管理

「量化工作量考核

，趣范测试

（4）加强协调与沟通

2010-4-630

第八章•目录

8.1软件配置及其管理的概念

8.3配置管理需求

8.4版本管理

8.5变更管理

8.6配置状态监测与报告

8.7基于配置管理的软件项目管理

8.8配置管理的技术手段和工具

8.2配置管理活动和流程

8.2.1主要配置管理活动

8.2.2项目经理的配置管理流程

变更控制

■，♦版本控制

):♦评审

♦:♦统计

■二--。软件编译、连接和发放管理

2010-4-633

g-'一一-一'■一

工女,口％加心中3k

I对

工匚帚—币[=[

囱置管理，大致可以分为以

计划顼目配置下步骤：

与变更控制

（1）拟订项目的配置

管理计划；（2）创建项

目的配置管理环境；

由（3）进行项目的配置管

用法以目CM小境理活动，包括：标识配置

项；管理基线和发布活

动；监测与报告配置状

囱态；管理变更请求。

ffi（1）和（2）可以看成配

变更与交付配置JJl管理变更请求置管理的准备，（3）是

配置管理的具体实施。配

_____V____置管理的具体实施，在

RUP定义为四个管理活

动。

2010-4-634

^SoftwareConfj，口

对于配置顼

信息可售-r-r-

计算二机程序（源代码和可执行程序）

豺算机程序的文档（针对技术开发者和用户）

髅薜建存在程序内部或外部）。

懑包含了所有在软件过程中产生的信息，总称为软件配置

.二

宇孝唯CMM2中，除上述3个配置项以外，还包括项目管理的有关文件、

^^＜息记录等。

由此可见，配置项的识别是配置管理活动的基础，也是制定配置

管理计划的重要内容。

2010-4-635

配置

软件配置管理认为外AC\的拜发过狸是・个7

在不严重踽跷-"prrr

”基线JI5Line)”这一■概念。

,线的定义是这样的:“已经正式通过审核批准的某规约或产

眦可作为进一步开发的基础，并且只能通过正式的变化控

:改变。”

松；根据这个定义，我们在软件的开发流程中，也可以把所有需

要加以控制的配置项分为基线配置项和非基线配置项两类，例如：

一基线配置项可能包括所有的设计文档和源程序等；非基线配置项可

能包括项目的各类计划和报告等。

有关配置项的内容，我们将在后面，专门花一节的篇幅，进行讨

论。

2010-4-6

为标识和控制

所:呻~pj，7,­〜丁”~vvvI»二-*/—应」I的T模I,、■

i中的规定章节（部分）记录对象的标

q在引入软件配置管理工具进行管理后，这些配

加以摩定的目录结构保存在配置库中。

霸置项的操作权限应由配置管理员严格管理，基本

期谑寸基线配置项向软件开发人员开放读取权限；非

髅配置项向项目经理、配置控制委员会及相关人员开

三诙--

2010-4-637

在引，

要求二

置库;混芋储池）中去，或是直接工作在软件配置管理工

具提供豳I环境之下（根据配置管理构架提供的控制方式

同）o

跄开发人员按照任务的要求，在不同的开发阶段，工

聿平自在不同的工作空间上。

比较理想的情况是把整个配置库视为一个统一的工作空

间，然后再根据需要把它划分为个人（私有）、团队

（集成）和全组（公共）这三类工作空间（分支）,从

而更好的支持将来可能出现的并行开发的需求。

2010-4-638

以际需道笄源证版本命名的

版本在生成过程中，自动依照设定的使用模型

西、演进。除了系统自动记录的版本信息以外，

鼎件开发流程的各个阶段，我们还需要定义、

些元数据来记录版本的辅助信息和规范开发流

■r为今后对软件过程的度量做好准备。当然如果选

1■的工具支持的话，这些辅助数据将能直接统计出过程

=啜据，从而方便我们软件过程改进(SoftwareProcess

m$BEovement,SPI)活动的进行。

对于配置库中的各个基线控制项，应该根据其基线的位

置和状态来设置相应的访问权限。一般来说，对于基线

版本之前的各个版本都应处于被锁定的状态，如需要对

它们进行变更，则应按照变更控制的流程来进行操作。

2010-4-639

变更管理的一般流程基

（1）＜0次变更请求;

（2、庄蝎CB审核并决定是否批准；

）分配请求，修改人员提取配置项，进行修改;

（4）

（5）提家修改后的配置项;

于建立测试基线并测试;

I幻灌建软件的适当版本;

♦

餐二-（8）复审（审计）所有配置项的变化;

的发布新版本。

在这样的流程中，配置管理员通过软件配置管理工具来进行

访问控制和同步控制，而这两种控制则是建立在前面所描述的版

本控制和分支策略的基础上的。

2010-4-640

口管置库结构和相关说明;

开发起始基线的构成；

(3)当前基线位置及状态;

B一翎各基线配置项集成分支的情况；

工学一⑸各私有开发分支类型的分布情况;

⑹关键元素的版本演进记录;

(7)其它应报告的事项。

2010-4-641

配置审计的年

买买:做

部分“但当软件配置管理是一个正式的活动时该活动由SQA人员单

独执行“

总件配置管理的对象是软件研发活动中的全部开发资产。所

有出冬切都应作为配置项纳入管理计划统一进行管理，从而能够保

感时的对所有软件开发资源进行维护和集成。因此，软件配置管

囹主要任务也就归结为以下几条:

’139辆定项目的配置计划;

-_（2）«寸配置项进行标识;

（3）对配置项进行版本控制；

（4）对配置项进行变更控制；

（5）定期进行配置审计；

（6）向相关人员报告配置的状态。

2010-4-642

是；

制定CL1第略场写CN1计划

配置经理（1）确定项目配置

管理策略

（2）确定用于控制

产品变更的策略

理立变更和流程

变更控制经理控制流程

（3）在配置管理计

划（是软件开发

O:计划的一部分）

D中记录此信息

吭目经理制定软件开发

计划（从项目

管理工作流程）

.7崎颦策略-

一

*»r/\I—[FI|i乒[l/|JH「I/一I*"J…r—(pl…匕啊展•好和报与已经批准用.

_L■r\-C7i—■t々建

季的TTOfg力嘴藐前莪赢定操

于期目尊Bfefei熊绷能叫.

作题目工件的保护是通过归档、建立基线和报告等

操作位i实现的：。-

/-k-rrr

但用隔蹩的，已记录下来的墓■FiI的目的是：确保

做的变更保持一致，并将产品的状态、对其所

变更以及这些变更所耗费的成本及对时间表的影响

关的涉众。

软件配置管理计一:5划说明在产品/项目生命周期中要执行的所

k二L:——・有―—与―配-置---管〜-理yf7V相关的活动。它记录如何计划、实施、控

二一一制和组织与产品相关的配置管理活动。

2010-4-644

■-,----…：………—…•一一一-■---■,ijr-r：---

:较理想的软件开发团队中，需要哪些角

目组的项目经理

■fit计划和策略的配置经理

软件产品开发与维护的软件工程人员

臂邀责验证产品正确性的测试人员

一一一贪责确保产品高质量的质量保证经理

使用产品的用户。

2010-4-645

■■

执行L1同时使有关项目的信息容易获

手更改形成控制，配置经理引入规范的请求变更

那评估更改的机制（通过变更控制机构CCB,由

藜责批准对软件系统的变更），和批准变更的机制。

置经理负责为工程人员创建任务单，交由项目经理对任

工务进行分配，创建项目的框架。同时，配置经理还收集

「软件系统中构件的相关数据，比如说用以判断系统中出

.现问题的构件的信息。

2010-4-646

第八章•目录

8.1软件配置及其管理的概念

8.2配置管理活动和流程

8.4版本管理

8.5变更管理

8.6配置状态监测与报告

8.7基于配置管理的软件项目管理

8.8配置管理的技术手段和工具

8.3配置管理需求

8.3.1配置管理的对象

8.3.2最基本的配置管理项——文档

8.3.3UCM目录结构下的配置管理对象

8.3.1配置管理对象

/配置管理!的第一个基本活动是配置标识，通俗地讲，也就是查询、识

别和确定配置管理

过程中置管理的对

/配置管理〔对象呈现为一种层次结构，因此，为了标识配置管理的对

■需要对软件系统进行分解：

目前于分解软件系统的术语有多种多样，没有被标准化。

谣lumphery定义了5个层次：系统、子系统、产品、构件和模

一L尊Whitgift定义了3个层次：系统、子系统和元素。

IEEE定义了3个层次：计算机配置项、计算机软件构件和计算机软件

-■-W-

一•-RUP定义了4个层次：系统、实施(或构件)子系统、构件和文件

(RUP5.51999)o

2010-4-649

/在RUP®!

是处于版军控ygrrai

录,构I层次要高于元素

（文件矛目录），构件把元素

组织起来片一个版本控制的构

2体的物理的对象,

个根目录。这个根目

以及从根目录下所属的所

知文件，是系统的一个

,统。大的系统有多个根目

二二二鎏1（子系统），小系统则可能

一只有一个根目录。

•产品目录结构为所有可具有版本号的、与产品相关的工件提供逻辑

嵌套的占位符。工件是开发流程生命周期的结果，用于开发整个系统

的各组成部分（构件）。

2010-4-650

配置管理对象

/首先找I1从根目录开始（I有一个根目录的小）系统，讨论软

件系统架^目;里方冽的生

起一喂i架。软件的体系构架在软件工程时代被称为系统结构。

在皿L嚣,被称为构架。

UML对构3I勺定义是:

软件系统组织结构的重要决定；

（2）结;■素和接口的选取，确保它们的行为能满足这些要素之间的

系；

开励瑜构要素和行为要素以一种渐进的方式被组装成子系统，能够指

一二二导这种组织结构的结构风格，要素的内容，它们的接口、它们的协作

一艇犯的组.合。

一•-系凄或系统构架是由子系统（构件）组成的。

2010-4-651

腌努成三种构件7邮置型构件、工作产

举是撷署到嘱标枇询的画

勤皮其他支持O

工作翱例期a源文件、卷文件迎

一抬

型构件：是指由运行于目标机的系统生成的内容，例如:

再度看系统架构，我们主要关注的是在开发环境中以及将来

示系统中的系统的物理层面的文件和目录结构、分组和版本

91关注决定了配置管理的对象以及对象的“粒度”。

淆些项目使用高层次的设计文档来描述架构，例如：模型、视

星用霹布高层架构描述中，逻辑上的“类”，可影射对应为物理层面的

一・彳乍为软件产品和软件过程，这些文件和目录是SCM控制的对象，即他

一们是配置项。在我们现在的讨论中，有时，我们说明这些文件是用于

管理和设计系统的内容（包括：项目计划、设计模型、测试报告）

等，有些是实现系统设计的文件（包括：源代码、库、执行文件

等），有时，把它们不加区别地看成为构件。

2010-4-652

」可作之项/单元标识的软件工作产品实例有：

与过程相1关的文档（例如：计划、标准或规程）

交件需求

F设计

软件代码单元

三软件测试规程

一为软件测试活动建立的软件系统

一交付给客户或最终用户的软件系统

七一编译程序

二一其他支持工具

不论各体系是如何定义的，我们基本可以认为，配置管理的对象，主

要地可以分为二类：软件产品和文档。软件产品比较容易标识，而文

档相对比较复杂。我们将重点进行讨论。

2010-4-653

8.3.2最基本的配置管理项——文档

*—■“

/文档在i饮件开发人员、软件管理人员、维护人员、用户以及计算机之

____________用.开发人一彳在软件「牛命

覆麻确需每个作

T作为前阶段工作成果的体现和方

用是显而（易见的。这部分文档通常称为开发文档。

/软件开还匕程中软件开发人员需制定一些工作计划或工作报告，这些

聒都要提供给管理人员，并得到必要的支持。管理人员则

■这些文档了解软件开发项目安排、进度、资源使用和成果等。

靠险文档通常称为管理文档，或称为项目文档。

发人员需为用户了解软件的使用、操作和维护提供详细的资

三就整部分文档通常称为用户文档。

2010-4-654

我们把这三种文档所包括的内容列在下图中。其中列举了十三

个文档，这里对它们做一些简要说明：

H用户手册

II操作手册

川广乂档||维护修改建议

||软件需求（规格）说明书

软件需求（规格）说明书

数据要求说明书

概要设计说明书,

详细设计说明书

可行性研究报告

项目开发计划

项目开发计划

测试计划

管理文档n测试报告

一II开发进度月报J

开发总结报告

2010-4-6u55

的作用

所提问题

为何

文档

可行性研究托

项目开发计为/

软件需求说明-7

数据要求说明■/•/

概要设计-;-

-——

用户手册

操作手册

I■"

测试分析报更

开发进度月报

I项目开发总结

建议

-

二—=g)工作流(Stream)：

-(?)项目(Project)：

2010-4-658

第八章•目录

8.1软件配置及其管理的概念

8.2配置管理活动和流程

8.3配置管理需求

8.5变更管理

8.6配置状态监测与报告

8.7基于配置管理的软件项目管理

8.8配置管理的技术手段和工具

8.4版本管理

8.4.1版本管理的必要性

8.4.2此前的版本管理

8.4.3元素、分支与版本

8.4.4构件、基线与存储池

8.4.5现代版本管理活动

2010-4-660

一名目I-4

考些问题，具体地说就是如下一些问题:

嬲医顼目进行整体管理；

发小组的成员之间如何以一种有效的机制进行协调;

M喇府小组成员各自承担的子项目的统一管理；

对研发小组各成员所作的修改进行统一汇总;

舒辆7保贸修改的轨迹，以便撤销错误的改动；

大雷日对在研发过程中形成的软件的各个版本如何进行标识，管理及差异

二个非常直接的反应是，我们必须要引进一种管理机制，一个版本管理

机制，而且是广义上的版本管理，它不仅需要对源代码的版本进行管

理，而且还要对整个项目进行管理。

2010-4-661

8.4.2早前的版本管理

＞在鬻节I程时代，面可这佞的而L我、们通过以往、的那种被誉建立具有

-W山L编,程风格的做法以诸，如能编—或.对..他..人..的.源2程序讲行修曲•时.洋

释口为，修改日期/如果是多个成贝同任

£能卜抵现二个库管理员，由他来控制什么人在访问哪个源代码，修改的人

向他报:告做了什么改动。如果有几个人同时改动，库管理员或者限定同

期一个人做修改，他记住这人是谁，或者他自己来做同时修改的

翻差鼻第较和综合，以便形成一个统一的新版本。在3-5人小组.，这

理员还能胜任，但这种做法在当前的大型软件的开发中已经越来

簸图雉了，因为靠人工的操作、靠个人的自觉、靠库管理员的维护，充

■是一种以小作坊的形式来面对软件的社会化大生产，再也不可能行

底意通子箕

关等旗交件目录的版本管理

―三宏版本控制工具出现之前，或者，现在国内很多的软件企业，并不用什么

〜一版本控制工具。他们也做一些简单的版本控制工作。他们是怎么做的？

-最简单的办法是使用文件拷贝支持不同的版本。具体地讲，就是项目组在项

目组的文件共享服务器上，建立一个项目组文件系统，在文件系统下，对涉

及到的文件，建立不同的版本目录，从个人工作区到系统发布版，包括中间

结果，甚至可能是所有文件。库管理员不断地增加目录的标签，以标识历史

前进的步伐。

2010-4-662

8.4.2早前的版本管理

工『

一创建和存放文件的多个版本；

处t种或几种锁定装置，强制对文件的修改顺序;

啕睡文件的版本;

&）从历史目录中找回旧版本。

工具基本上能帮助库管理员从手工的管理中解脱出

乘，开发人员不需要库管理员的介入，可以自己从库中检

r人和检出文件，当文件被检出后，其他人暂时不能再检出

.此文彳牛。同时，在必要的时候，文侔的一个新版未被创

2010-4-663

8.4.2早前的版本管理

例如；M蝴NSS版本控制是通过以下方式实现的:

>VSS提供版茎筌制历

复的

>侬用谶明/时间戳来记录文件是何时被Check-out或是何时被修改

蓼有亶中方法来跟踪文件和项目的版本：

><is毒;这是由VSS维护的内部数码，用户对它没有控制权。每

，下文件和项目的每个版本都有一个版本号，这些版本号总是一个整数

眩-

标签:这些是用户赋给某个项目或文件的某个版本的一个字符

可以是任何格式的长度不超过31字符的字符串。

—A/3)-日期/时间戳：它给出了一个文件何时最后被修改的信息，或者

一是一个文件何时被Check-in。VSS同时支持12小时和24小时的时间格

.式。

2010-4-664

原子对象

在c1—血就豳战废?甲尸给卢般明圈胪型解为JJ7G5T?,

整一①为

),兀系TH乂TT不凯:对外;脚b凿嗦;啥兜素记录了它所代表

的文件福目录的版本「所以，当用户检入文件时，就创建了那个元素的新版

本。元素也前织成不同的分支。分支是线形的版本序列，版本序列构成的是

并行开喊?顼目或基于统一基线开始的不同的系统。元素都被保存在存储池

M/0B；中一存下图是存储池、元素、分支、版本之间的关系:

存储池元素分支版本

.在ClearCase中，每一个元素都以一个主分支(mainbranch)和一个不包含任

何内容的零版本序列开始，称为“/main/0”。每一次新版本检入，在主分支上

创建版本1

2010-4-665

\main的

加0左图的版本树中，长方形表示

一个分支，圆形表示检入的时

间排谆的版本号；箭头表示从

1

\rel2\rell_bugfix一个分支到另一个分支的变更

回归（归并）。“发布版本

0201.0/1.1”是这个版本上的标

签。目录是元素，也是版本对

131象。ClearCase对目录与文件一

样，也进行版本管理。为了能

在前一个版本中修复BUG,或者

242