情景情景 3.1 3.1 软件项目管理软件项目管理

2

大型软件工程项目的失败 ---- 才使人们逐渐认识到软件项目管理的重要性和特殊性。失败的原因 ---- 不是软发工程师无能，而主要是管理不善。所谓管理 ---- 就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。软件项目管理 ---- 先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。软件项目管理 ---- 从一组项目计划活动开始，其基础是工作量估算和完成期限估算。

3

13.1 估算软件规模13.1.1 代码行技术• 代码行技术是比较简单的定量估算软件规模的方法。• 为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做出估计。每个人都估计程序的最小规模 (a) 、最大规模 (b) 和最可能的规模 (m) ，分别算出这 3 种规模的平均值，再用下式计算程序规模的估计值 L =

单位是代码行数（ LOC ），或是千行代码数（ KLOC）

64 bma

4

代码行技术的主要优点：代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。代码行技术的缺点： 源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。为了克服代码行技术的缺点，人们又提出了功能点技术。

5

13.1.2 功能点技术 功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（ FP ）为单位度量软件规模。1. 信息域特性 功能点技术定义了信息域的 5 个特性：（ 1 ） 输入项数 (Inp) ： 用户向软件输入的项数，这些输入给软件提供面向应用的数据。输入不同于查询，后者单独计数，不计入输入项数中。（ 2 ） 输出项数 (Out) ： 软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和出错信息等。报表内的数据项不单独计数。（ 3 ） 查询数 (Inq) ： 查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。（ 4 ） 主文件数 (Maf) ： 逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。（ 5 ） 外部接口数 (Inf) ： 机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。

6

2. 估算功能点的步骤（ 1 ） 计算未调整的功能点数 UFP 首先，把产品信息域的每个特性 (即Inp 、 Out 、 Inq 、 Maf 和 Inf) 都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数（例如，一个简单级的输入项分配 3 个功能点，一个平均级的输入项分配 4 个功能点，而一个复杂级的输入项分配 6 个功能点）。 然后，用下式计算未调整的功能点数 UFP ： UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf其中， ai(1≤i≤5) 是信息域特性系数，其值由相应特性的复杂级别决定，如表 13.1 （见书 297页）所示。

7

(2) 计算技术复杂性因子 TCF 这一步骤度量 14 种技术因素对软件规模的影响程度。这些因素包括高处理率、性能标准（例如，响应时间）、联机更新等，在表 13.2 （见书 297页）中列出了全部技术因素，并用Fi(1≤i≤14) 代表这些因素。根据软件的特点，为每个因素分配一个从 0 （不存在或对软件规模无影响）到 5 （有很大影响）的值。然后，用下式计算技术因素对软件规模的综合影响程度 DI ： DI=

技术复杂性因子 TCF 由下式计算： TCF=0.65+0.01×DI 因为 DI 的值在 0~70 之间，所以 TCF 的值在 0.65~1.35 之间。

14

1iiF

8

（ 3 ） 计算功能点数 FP

用下式计算功能点数 FP ： FP=UFP×TCF 功能点数与所用的编程语言无关，看起来功能点技术比代码行技术更合理一些。但是，在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。

9

13.2 工作量估算 软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（ KLOC 或 FP ）的函数，工作量的单位通常是人月（ pm) 。 支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境。

10

13.2.1 静态单变量模型这类模型的总体结构形式如下： E=A+B×(ev)C

其中， A 、 B和 C是由经验数据导出的常数， E是以人月为单位的工作量， ev 是估算变量（ KLOC 或 FP ）。下面给出几个典型的静态单变量模型。1. 面向 KLOC 的估算模型(1) Walston_Felix 模型 : E=5.2×(KLOC)0.91

(2) Bailey_Basili 模型 : E=5.5+0.73×(KLOC)1.16

(3) Boehm 简单模型 : E=3.2×(KLOC)1.05

(4) Doty 模型（在 KLOC>9 时适用） : E=5.288×(KLOC)1.047

11

2. 面向 FP 的估算模型 (1) Albrecht & Gaffney 模型 E=-13.39+0.0545FP (2) Maston,Barnett 和 Mellichamp 模型 E=585.7+15.12FP

从上面列出的模型可以看出，对于相同的 KLOC 或 FP 值，用不同模型估算将得出不同的结果。主要原因是，这些模型多数都是仅根据若干应用领域中有限个项目的经验数据推导出来的，适用范围有限。因此，必须根据当前项目的特点选择适用的估算模型，并且根据需要适当地调整（例如，修改模型常数）估算模型。

12

13.2.2 动态多变量模型 动态多变量模型也称为软件方程式，它是根据从 4000 多个当代软件项目中收集的生产率数据推导出来的。该模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下： E=(LOC×B0.333/P)3×(1/t)4

(13.2)其中，E是以人月或人年为单位的工作量；t是以月或年为单位的项目持续时间；B是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（ KLOC=5~15 ）， B=0.16, 对于超过 70 KLOC 的程序， B=0.39;

P是生产率参数，它反映了下述因素对工作量的影响： 总体过程成熟度及管理水平； 使用良好的软件工程实践的程度； 使用的程序设计语言的级别； 软件环境的状态； 软件项目组的技术及经验； 应用系统的复杂程度。开发实时嵌入式软件时， P的典型值为2000 ；开发电信系统和系统软件时， P=10000 ；对于商业应用系统来说， P=28000 。可以从历史数据导出适用于当前项目的生产率参数值。 从（ 13.2 ）式可以看出，开发同一个软件（即 LOC固定）的时候，如果把项目持续时间延长一些，则可降低完成项目所需的工作量。

13

13.2.3 COCOMO2 模型COCOMO 是构造性成本模型（ constructive cost model) 的英文缩写。1981 年 Boehm 在《软件工程经济学》中首次提出了 COCOMO 模型。1997 年 Boehm 等人提出的 COCOMO2 模型，是原始的 COCOMO 模型的修订版，它反映了十多年来在成本估计方面所积累的经验。

COCOMO2 给出了 3 个层次的软件开发工作量估算模型，这 3 个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。这些模型既可以用于不同类型的项目，也可以用于同一个项目的不同开发阶段。这 3 个层次的估算模型分别是 （ 1 ） 应用系统组成模型。这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。 （ 2 ） 早期设计模型。这个模型适用于体系结构设计阶段。 （ 3 ） 后体系结构模型。这个模型适用于完成体系结构设计之后的软件开发阶段。

14

下面以后体系结构模型为例，介绍 COCOMO2 模型。该模型把软件开发工作量表示成代码行数（ KLOC ）的非线性函数： E= (13.3)其中 : E 是开发工作量（以人月为单位）， A 是模型系数， KLOC 是估计的源代码行数（以千行为单位）， B 是模型指数， fi(i=1~17) 是成本因素。 每个成本因素都根据它的重要程度和对工作量影响大小被赋予一定数值（称为工作量系数）。这些成本因素对任何一个项目的开发工作量都有影响，即使不使用 COCOMO2 模型估算工作量，也应该重视这些因素。 Boehm 把成本因素划分成产品因素、平台因素、人员因素和项目因素等 4 类。 表 13.3 （见书 300页）列出了 COCOMO2 模型使用的成本因素及与之相联系的工作量系数。

17

1ii

b fKLOCa

15

13.3 进度计划• 项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。为达到上述目标，管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。• 软件项目的进度安排是通过把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工作量分布于计划好的项目持续期内。• 进度计划将随着时间的流逝而不断演化。在项目计划的早期，首先制定一个宏观的进度安排表，标识出主要的软件工程活动和这些活动影响到的产品功能。随着项目的进展，把宏观进度表中的每个条目都精化成一个详细进度表，从而标识出完成一个活动所必须实现的一组特定任务，并安排好了实现这些任务的进度。

16

软件开发小组人数与软件生产率的关系 当几个人共同承担软件开发项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务之间的接口问题，即所谓通信问题。通信需花费时间和代价，会引起软件错误增加，降低软件生产率。

17

若两个人之间需要通信，则称在这两个人之间存在一条通信路径。如果一个软件开发小组有 n 个人，每两人之间都需要通信，则总的通信路径有 n(n-1)/2 ( 条 ) 。

18

设一个人单独开发软件，生产率是 5000 行／人年。若 4 个人组成一个小组共同开发这个软件，则需要 6 条通信路径。若在每条通信路径上耗费的工作量是 250 行／人年。则小组中每个人的软件生产率降低为 5000 － 6×250 ／ 4 ＝ = 5000 － 375 ＝ = 4625 行／人年。

19

从上述分析可知，一个软件任务由一个人单独开发，生产率最高；而对于一个稍大型的软件项目，一个人单独开发，时间太长。因此软件开发小组是必要的。 但是，开发小组不宜太大，成员之间避免太多的通信路径。 在开发进程中，切忌中途加人，避免太多的生产率损失。

20

任务的确定与并行性 当参加同一软件工程项目的人数不止一人的时候，开发工作就会出现并行情形。 软件开发进程中设置许多里程碑。里程碑为管理人员提供了指示项目进度的可靠依据。 软件工程项目的并行性提出了一系列的进度要求。

21

22

因为并行任务是同时发生的，所以进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。 项目负责人应注意构成关键路径的任务，即若要保证整个项目能按进度要求完成，就必须保证这些任务要按进度要求完成。

23

制定开发进度计划 40 － 20 － 40 规则

在整个软件开发过程中，编码工作量仅占 20 ％，编码前工作量占 40％，编码后工作量占 40 ％。 40 － 20 － 40 规则只应用来做为 一个指南。实际的工作量分配比例必须按照各项目的特点来决定。

24

估算开发时间 T 的方程 : (1) Walston_Felix模型 T=2.5E0.35

(2) 原始的 COCOMO模型 T=2.5E0.38

(3) COCOMO2模型 T=3.0E0.33+0.2×(b-1.01)

(4) Putnam模型 T=2.4E1/3

其中， E 是开发工作量（以人月为单位）， T 是开发时间（以月为单位）。

25

进度安排的方法 可以把用于一般开发项目的进度安排的技术和工具应用于软件项目。 为监控软件项目的进度计划和工作的实际进展情况，为表现各项任务之间进度的相互依赖关系，需要采用图示的方法。 在图示方法中，必须明确标明：

26

各个任务的计划开始时间，完成时间； 各个任务完成标志（即○文档编写和△评审）； 各个任务与参与工作的人数，各个任务与工作量之间的衔接情况； 完成各个任务所需的物理资源和数据资源。

27

(1) 甘特图（ Gantt Chart ） 在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是以必须交付应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。

28

29

(2) PERT 技术和 CPM 方法 PERT 技术叫做计划评审技术， CPM方法叫做关键路径法，它们都是安排开发进度，制定软件开发计划的最常用的方法。 它们都采用网络图来描述一个项目的任务网络，也就是从一个项目的开始到结束，把应当完成的任务用图或表的形式表示出来。

30

三个模块开发的网络图三个模块开发的网络图

31

通常用两张表来定义网络图。 一张表给出与一特定软件项目有关的所有任务（也称为任务分解结构

WorkBreakdown Structure ） ; 另一张表给出应当按照什么样的次序来完成这些任务（有时称为限制表

RestrictionList ）。PERT 技术和 CPM 方法都为项目计划人员提供了一些定量的工具。

32

确定关键路径，即决定项目开发时间的任务链。在关键路径上的各个任务都是时间余量为零的关键任务，不能有任何时间延误。 应用统计模型，对每一个单独的任务确定最可能的开发持续时间的估算值。 计算边界时间，以便为具体的任务定义时间窗口。

33

项目的追踪和控制软件项目管理一项重要工作就是在项目实施过程中进行追踪和控制： 定期举行项目状态会议。由每位项目成员报告其进展和遇到的问题。 评价在软件工程过程中所产生的所有评审的结果。 确定由项目的计划进度所安排的可能选择的正式的里程碑。

34

比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始时间。 非正式地与开发人员交谈，以得到他们对开发进展和刚冒头的问题的客观评价。 当问题出现的时候， 项目管理人员必须实行控制以尽快地排解问题。

35

13.4 软件项目的组织与计划 制定计划 软件项目组织的建立 人员配备

36

★ 制定计划 软件开发项目的计划涉及到实施项目的各个环节，带有全局性质。 计划的合理性和准确性往往关系着项目的成败。 计划应力求完备。要考虑到一些未知因素和不确定因素，考虑到可能的修改。计划应力求准确。尽可能提高所依据数据的可靠程度。

37

1. 制定计划目标和进行风险分析 制定计划的目的就是要回答：这个软件项目的范围是什么？需要哪些资源？花费多少工作量？要用的成本有多少？以及进度如何安排等等一系列问题。 这步工作应当以系统计划为基础，以系统规格说明为依据。

38

在开发工作尚未开始之前，准确回答这些问题是十分困难的。需要通过以往的开发经验做出估算，很难达到准确。 从估算出发，项目必然带有一定的风险。估算的准确性越差，风险也就越大。研制的软件项目越复杂，规模越大，结构化程度越低，资源、成本、进度等因素的不确定性越大，承担这一项目所冒的风险也越大。

39

组织软件项目必须事先认清可能构成风险的因素，并研究战胜风险的对策，只有这样才能避免出现灾难性的后果，取得项目预期的成果。

40

2. 软件计划的类型 针对不同工作目标，软件计划有： 项目实施计划（软件开发计划） 这是软件开发的综合性计划，通常应包括任务、进度、人力、环境、资源、组织等多个方面。 质量保证计划 把软件开发的质量要求具体规定为每个开发阶段可以检查的质量保证活动。

41

软件测试计划 规定测试活动的任务、测试方法、进度、资源、人员职责等。 文档编制计划 规定所开发项目应编制的文档种类、内容、进度、人员职责等。 用户培训计划 规定对用户进行培训的目标、要求、进度、人员职责等。

42

综合支持计划 规定软件开发过程中所需要的支持，以及如何获取和利用这些支持。 软件分发计划 软件开发项目完成后，如何提供给用户。

43

3. 项目实施计划中任务的划分 如何进行工作划分是实施计划首先应解决的问题。常用的计划结构有： 阶段项目计划 按软件生存期，把开发工作划分为若干阶段，对每一阶段工作做出计划。再把每一阶段工作分解为若干任务，做出任务计划。还要把任务细分为若干步骤，做出步骤计划。

44

任务分解结构 按项目的实际情况进行自顶向下的结构化分解，形成树形任务结构。进一步把工作内容、所需工作量、预计完成的期限也规定下来。 任务责任矩阵 在任务分解的基础上，把工作分配给相关的人员，用一个矩阵形表格表示任务的分工和责任。

45

任务分解结构

46

任务责任矩阵

47

★ 软件项目组织的建立 开发组织采用什么形式，要针对软件项目的特点来决定，同时也与参与人员的素质有关。1、组织原则 (1) 尽早落实责任： 在软件项目工作开始时，要尽早指定专人负责。使他有权进行管理，并对任务的完成负全责。

48

（ 2 ）减少接口： 一个组织的生产率随完成任务中存在的通信路径数目增加而降低。要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失。 （ 3 ）责权均衡： 软件经理人员所负的责任不应比委任给他的权力还大。

49

2. 组织结构的模式 （ 1 ）按课题划分的模式 把软件开发人员按课题组成小组，小组成员自始至终参加所承担课题的各项任务。他们应负责完成软件产品的定义、设计、实现、测试、复查、文档编制、甚至包括维护在内的全过程。

50

（ 2 ）按职能划分的模式 把参加开发项目的软件人员按任务的工作阶段划分成若干个专业小组。要开发的软件产品在每个专业小组完成阶段加工（即工序）以后，沿工序流水线向下传递。例如，分别建立计划组、需求分析组、设计组、实现组、系统测试组、质量保证组、维护组等。各种文档资料按工序在各组之间传递。

51

（ 3 ）矩阵形模式 这种模式实际上是以上两种模式的复合。一方面，按工作性质，成立一些专门组，如开发组、业务组、测试组等；另一方面，每一个项目又有它的经理人员负责管理。每个软件人员属于某一个 专门组，又参加某一项目的工作。

52

53

3. 程序设计小组的组织形式 小组内部人员的组织形式对生产率也有影响。现有的组织形式有三种。 （ 1 ）主程序员制小组 小组的核心由一位主程序员 ( 高级工程师 )、二至五位技术员、一位后援工程师组成。主程序员负责小组全部技术活动的计划、协调与审查，设计和实现项目中的关键部分。

54

技术员负责项目的具体分析与开发，文档资料的编写工作。后援工程师支持主程序员的工作，为主程序员提供咨询，也做部分分析、设计和实现的工作。并在必要时能代替主程序员工作。 主程序员制小组还可以由一些专家( 如通信专家或数据库设计专家 )、辅助人员 ( 如打字员和秘书 )、软件资料员协助工作。

55

（ 2 ）民主制小组 在民主制小组中，遇到问题，组内成员之间可以平等地交换意见。工作目标的制定及做出决定都由全体成员参加。虽然也有一位成员当组长，但工作的讨论、成果的检验都公开进行。这种组织形式强调发挥小组每个成员的积极性。有人认为这种组织形式适合于研制时间长、开发难度大的项目。

56

（ 3 ）层次式小组 在层次式小组中，组内人员分为 三级：组长（项目负责人）一人负责全组工作，包括任务分配、技术评审和走查、掌握工作量和参加技术活动。 他直接领导二至三名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。

57

这种组织结构只允许必要的人际通信。比较适用于项目本身就是层次结构的课题。因为这样可以把项目按功能划分成若干个子项目，把子项目分配给基层小组，由基层小组完成。 这种组织方式比较适合于大型软件项目的开发。

58

59

★ 人员配备 如何合理地配备人员，也是成功地完成软件项目的切实保证。所谓合理地配备人员应包括：

按不同阶段适时任用人员 恰当掌握用人标准。

60

1. 项目开发各阶段所需人员 一个软件项目完成的快慢，取决于参与开发人员的多少。 在开发的整个过程中，多数软件项目是以恒定人力配备的。 实际人力需求与开发进度的关系如下图中的曲线所示。

61

62

按此曲线，需要的人力随开发进展逐渐增加，在编码与单元测试阶段达到高峰，以后又逐渐减少。 如果恒定地配备人力，在开发初期将会有部分人力资源用不上而浪费掉。在开发中期，需要人力不够，造成进度的延误。在开发后期就需要增加人力以赶进度。 恒定地配备人力将浪费人力资源。

63

2. 配备人员的原则 重质量 软件项目是技术性很强的工作，要任用少量有实践经验、有能力的人员去完成关键性的任务。 重培训 培养所需技术人员和管理人员是有效解决人员问题的好方法。 双阶梯提升 人员提升应分别按技术职务和管理职务进行，不能混在一起。

64

3. 对项目经理人员的要求 软件经理人员是工作的组织者，他的管理能力的强弱是项目成败的关键。他应具有以下能力： 把用户提出的非技术性要求加以整理提炼 , 以技术说明书的形式转告给分析员和测试员。 能说服用户放弃一些不切实际的要

求 , 以保证合理的要求得以满足。

65

能够把表面上似乎无关的要求集中在一起 , 归结为 “需要什么” , “ 要解决什么问题”。这是一种综合问题的能力。 要懂得心理学 , 能说服上级领导和用户，让他们理解什么是不合理的要求。但又要使他们毫不勉强 , 乐 于接受，并受到启发。

66

4. 评价人员的条件 软件项目中人的因素越来越受重视。在评价和任用软件人员时，必须掌握一定的标准。人员素质的优劣常常影响到项目的成败。 牢固掌握计算机软件的基本知识和技能。 善于分析和综合问题，具有严密的逻辑思维能力。

67

工作踏实、细致 , 不靠碰运气，遵循标准和规范，具有严格的科学作风。 工作中表现出有耐心、有毅力、有责任心。 善于听取别人的意见，善于与周围人员团结协作，建立良好的人际关系。 具有良好的书面和口头表达能力。

13.5 质量保证1 软件质量 软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。

69软件质量因素与产品活动的关系

70

2 软件质量保证措施 软件质量保证（ software quality assurance

SQA ）的措施主要有： • 基于非执行的测试（也称为复审或评审），主要用来保证在编码之前各阶段产生的文档的质量；

• 基于执行的测试（即以前讲过的软件测试） ,需要在程序编写出来之后进行，它是保证软件质量的最后一道防线；

• 程序正确性证明，使用数学方法严格验证程序是否与对它的说明完全一致。

71

参加软件质量保证工作的人员，可以划分成下述两类： • 软件工程师通过采用先进的技术方法和度量，进行正式的技术复审以及完成计划周密的软件测试来保证软件质量。• SQA 小组的职责，是辅助软件工程师以获得高质量的软件产品。其从事的软件质量保证活动主要是： 计划，监督，记录，分析和报告。简而言之， SQA 小组的作用是，通过确保软件过程的质量来保证软件产品的质量。

72

软件质量保证具体措施1. 走 查2. 审 查3. 测 试4. 证 明

73

13.6 软件配置管理 （ SCM ） Software Configuration Management

在开发软件的过程中，变化（或称为变动）既是必要的，又是不可避免的。但是，变化也很容易失去控制，如果不能适当地控制和管理变化，势必造成混乱并产生许多严重的错误。 软件配置管理是在软件的整个生命期内管理变化的一组活动 ①标识变化； ②控制变化； ③确保适当地实现了变化； ④向需要知道这类信息的人报告变化。 配置管理是在软件项目启动时就开始，并且一直持续到软件退役后才终止的一组跟踪和控制活动。 软件配置管理的目标是，使变化更正确且更容易被适应，在必须变化时减少所需花费的工作量。

74

13.6.1 软件配置1. 软件配置项 ① 计算机程序（源代码和可执行程序）； ② 描述计算机程序的文档（供技术人员或用户使用）； ③ 数据（程序内包含的或在程序外的）。 为了开发出高质量的软件产品，软件开发人员不仅要努力保证每个软件配置项正确，而且必须保证一个软件的所有配置项是完全一致的。

75

2. 基线 IEEE 把基线定义为： 已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。

– 基线（ Baseline ）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。– 基线通常对应于开发过程中的里程碑（ Milestone ），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。– 通常将交付给客户的基线称为一个“ Release” ，为内部开发用的基线则称为一个“ Build” 。

76

13.6.2 软件配置管理过程 1 、 标识配置项 2 、 进行配置控制 3 、 执行配置审计 4 、 记录配置状态 配置控制是核心： 存取控制（开发库、基线库、产品库） 版本控制 变更控制 产品发布控制

77

13.6.3 常用配置管理工具1 、 SourceSafe

– SourceSafe 是 Microsoft 公司推出的配置管理工具，是 Visual Studio的套件之一。 SourceSafe是国内最流行的配置管理工具，用户量绝对是第一位。

– SourceSafe长得很象早先土气的文件管理器，的确难看。但是难看不碍事， SourceSafe 的优点可以用 8个字来概括“简单易用，一学就会”，这个优点是它老妈 Microsoft遗传下来的，是天生的。 – 虽然 SourceSafe 并不是免费的，但是在国内人们以接近于零的成本得到它，网上到处可以下载啊。当然 Microsoft也不在乎这个小不点的软件，它属于“买大件送小件”的角色。如果你合法地得到 Visual Studio，你就得到了免费的 SourceSafe 。

– SourceSafe的主要局限性：• 只 能 在 Windows 下 运 行 ， 不 能 在 Unix, Linux 下 运行。 SourceSafe不支持异构环境下的配置管理，对用户而言是个麻烦事。这不是技术问题，是微软公司产品战略决定的。•适合于局域网内的用户群，不适合于通过 Internet连接的用户群，因为 SourceSafe是通过“共享目录”方式存储文件的。

78

2 、 CVS – CVS 是 Concurrent Version System（并行版本系统）的缩写，它是著名的开放源代码的配置管理工具。 – CVS 的官方网站是 http://www.cvshome.org/ 。官方提供的是CVS服务器和命令行程序，但是官方并不提供交互式的客户端软件。许多软件机构根据 CVS官方提供的编程接口开发了各色各样的 CVS客户端软 件 ， 最 有名的 当推 Windows 环境的 CVS 客户端软 件——WinCVS 。 WinCVS是免费的，但是并不开放源代码。

– 与 SourceSafe相比， CVS的主要优点是：• SourceSafe 有的功能 CVS 全都有， CVS 支持并发的版本管理， SourceSafe 没有并发功能。 CVS 服务器的功能和性能都比SourceSafe高出一筹。

• CVS服务器是用 Java编写的，可以在任何操作系统和网络环境下运行。 CVS 深受 Unix 和 Linux 的用户喜爱。 Borland 公司的JBuilder 提供了 CVS 的插件， Java 程序员可以在 JBuilder集成环境中使用 CVS进行版本控制。

• CVS服务器有自己专用的数据库，文件存储并不采用 SourceSafe的“共享目录”方式，所以不受限于局域网，信息安全性很好。– CVS的主要缺点在于客户端软件，真可谓五花八门、良莠不齐。 Unix和Linux 的软件高手可以直接使用 CVS命令行程序，而 Windows用户通常使用 WinCVS。安装和使用 WinCVS显然比 SourceSafe麻烦不少，这是令人比较遗憾的。

79

3 、 ClearCase– IBM（ Rational公司）的 ClearCase是软件行业公认的功能最强大、

价格最昂贵的配置管理软件。 – ClearCase主要应用于复杂产品的并行开发、发布和维护，其功能划分为四个范畴：版本控制、工作空间管理（ Workspace Management ）、构造 管 理 （ Build Management ） 、 过 程 控 制 （ Process Control ）。 ClearCase 通过 TCP/IP 来连接客户端和服务器。另外， ClearCase拥有的浮动 License可以跨越 UNIX 和 Windows NT平台被共享。

– ClearCase 的功能比 CVS 、 SourceSafe强大得多，但是其用户量却远不如 CVS、 SourceSafe的多。主要原因是： • ClearCase价格昂贵，如果没有批量折扣的话，每个 License大约 5000 美元。对于中国用户而言，这无疑是天价。

• 用户只有经过几天的培训后（费用同样很昂贵），才能正常使用ClearCase。如果不参加培训的话，用户基本上不可能无师自通。

80

13.7 能力成熟度模型1、概述1） CMM是什么

– CMM （ Capability Maturity Model ）是用于衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。– 美国卡内基 -梅隆大学软件工程研究所（ SEI ）研制

2） 发展简史 – CMM 1.0 于 1991年制定。 – CMM 1.1 于 1993 发布，该版本应用最广泛。 – CMM 2.0草案于 1997年制定（未广泛应用）。 – 到 2000年， CMM演化成为 CMMI （ Capability Maturity Model

Integration ）， CMM 2.0 成为 CMMI 1.0 的主要组成部分。 – CMMI-SE/SW 1.1 （ CMMI for System Engineering and Software

Engineering ）于 2002年 1月正式推出。 3） CMM重要概念

– 5 个成熟度等级： Initial, Repeatable, Defined, Managed, Optimizing– 18个关键过程域。关键过程域指出为了达到某个成熟度等级必须要解决的一族问题。

81

4 ）能力成熟度模型的基本思想 ---- 帮助软件开发机构建立一个有规律的、成熟的软件过程。改进后的软件过程将开发出质量更好的软件，使更多的软件项目免受时间和费用超支之苦。5 ） CMM的策略 ---- 力图改进对软件过程的管理，而在技术方面的改进是其必然的结果。6 ） CMM在改进软件过程中所起的作用 ---- 指导软件机构通过确定当前的过程成熟度并识别出对过程改进起关键作用的问题，从而明确过程改进的方向和策略。通过集中开展与过程改进的方向和策略相一致的一组过程改进活动，软件机构便能稳步而有效地改进其软件过程，使其软件过程能力得到循序渐进的提高。

82

2 、 CMM 的五个级别• CMM 提供了将这些演化步骤组织为 5 个成熟度级别的框架，这为持续的过程改进提供了基础。• 成熟度级别定义了在使 软件过程成熟的过程 中的演化状态。

初始级(1)

可重复级(2)

已定义级(3)

已管理级(4)

严格的过程

标准的一致的过程

可预言的过程

持续改善的过程持续优化级

(5)

83

• 初始级– 组织：组织通常没有提供开发和维护软件的稳定的环境。– 项目：当发生危机时，项目通常放弃计划的过程，回复到编码和测试。– 过程能力：不可预测。 (unpredictable)

• 可重复级– 组织：将软件项目的有效管理过程制度化，这使得组织能够重复以前项目中的成功实践。– 项目：配备了基本的软件管理控制。– 过程能力：严格的。 (disciplined)

84

• 已定义级– 组织：在组织范围内开发和维护软件的标准过程被文档化，其中包括软件工程过程和管理过程，它们集成为一个一致的整体。– 项目：对组织的标准软件过程进行裁剪，来开发它们自己的定义软件过程。– 过程能力：标准的和一致的。 (standard and

consistent)• 已管理级

– 组织：为软件产品和过程都设定了量化的质量目标。– 项目：项目减小过程性能的变化性，使其进入可接收的量化边界，从而达到对产品和过程的控制。– 过程能力：可预言的。 (predictable)

85

• 持续优化级– 组织：关注于持续的过程改进。– 项目：软件过程被评价，以防止过失重复发生，从中获得的教训散布给其它项目。

– 过程能力：持续的改善。 (continuously improving)

86

3 、关于五个级别的说明• 从第 1级提升到第 2级可能需要几年的时间，在其它级别间提升通常依次需要 2 年的时间。• 由于每个级别形成了达到下一个级别的必须的基础，所以跳过级别是达不到预期的目标的。• 用途 --- 评定 (Assessment) 组使用 CMM ，识别组织的长处和弱点； --- 评价 (Evaluation) 组使用 CMM ，识别在不同的订约人之间进行风险的选择，并监控合同； --- 管理者和技术人员使用 CMM ，理解为他们的组织所制定的规划以及实现软件过程改善计划所需的活动； --- 过程改善组使用 CMM ，作为在他们的组织中定义和改善软件过程的指南。

87

4 、成熟度级别的内部结构成熟度级别

关键过程区域(KPA)

共同特征关键实践

过程能力目标

实现或制度化基础设施或活动

包含指示

组织达到

包含解决

描述

88

初始级 (1)

软件配置管理 软件质量保证 软件子合同管理 软件项目跟踪和监督 软件项目规划需求管理

可重复级 (2)

对等复审 组间协作 软件产品工程 集成的软件管理 培训计划 组织过程定义组织过程关注

定义级 (3)

软件质量管理量化的过程管理管理级 (4)

过程变化管理 技术变化管理错误预防

优化级 (5)

软件质量管理量化的过程管理

89

告一段落！