《软件工程导论》（第6版）第13章 软件项目管理 复习笔记

第13章　软件项目管理

一、软件项目管理总述

1．管理

管理是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。

2．软件项目管理 

软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算。

二、估算软件规模

1．代码行技术

（1）定义

代码行技术依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。是一种比较简单的定量估算软件估摸的方法。

（2）方法

①把实现每个功能的源程序行数累加起来，可得到实现整个软件所需要的源程序行数。

②估计程序的最小规模（a）、最大规模（b）和最可能的规模（m），分别算出这3种规模的平均值后，再用下式计算程序规模的估计值：

③程序小时用的单位是代码行数（LOC）；程序大时用的单位是千行代码数（KLOC）。

（3）优点

①代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。

②有以往开发类似产品的历史数据可参考时，估计出的数值比较准确。

（4）缺点

①源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模不太合理。

②用不同语言实现同一个软件所需要的代码行数并不相同。

③不适用于非过程语言。

2．功能点技术

（1）定义

功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。用功能点（FP）为单位度量软件规模。是为了克服代码行技术的缺点，提出来的新技术。

（2）信息域特性

①输入项数（Inp）：用户向软件输入的项数，这些输入给软件提供面向应用的数据。

②输出项数（Out）：软件向用户输出的项数，它们向用户提供面向应用的信息。

③查询数（Inq）：一次联机输入，它导致软件以联机输出方式产生某种即时响应。

④主文件数（Maf）：逻辑主文件（数据的一个逻辑组合）的数目。

⑤外部接口数（Inf）：机器可读的全部接口数量，用这些接口把信息传送给另一个系统。

（3）估算功能点的步骤

①计算未调整的功能点数UFP

a．把产品信息域的每个特性都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数。

b．用下式计算未调整的功能点数UFP：

其中，ai（1≤i≤5）是信息域特性系数，由相应特性的复杂级别决定，如表13-1所示。

表13-1 信息域特性系数值

②计算技术复杂性因子TCF

这一步骤度量14种技术因素对软件规模的影响程度，在表13-2中列出了全部技术因素，并用Fi（1≤i≤14）代表这些因素。

表13-2 技术因素

a．根据软件的特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。

b．用下式计算技术因素对软件规模的综合影响程度DI（0～70）：

c．技术复杂性因子TCF（0.65～1.35）由下式计算：

TCF=0.65+0.01×DI

③计算功能点数FP

用下式计算功能点数FP：

FP=UFP×TCF

功能点数与所用的编程语言无关，所以功能点技术比代码行技术更合理，但是，在判断信息域特性复杂级别和技术因素的影响程度时，功能点技术存在相当大的主观因素。

三、工作量估算

软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模的函数，工作量的单位通常是人月（pm）。没有一个估算模型可以适用于所有类型的软件和开发环境。

1．静态单变量模型

（1）形式

静态单变量模型的总体结构形式如下：

E=A+B×（eν）c

其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，eν是估算变量（KLOC或FP）。

（2）分类

①面向KLOC的估算模型

a．Walston_Felix模型

E=5.2×（KLOC）0.91

b．Bailey_Basili模型

E=5.5+0.73×（KLOC）1.16

c．Boehm简单模型

E=3.2×（KLOC）1.05

d．Doty模型（KLOC>9时适用）

E=5.288×（KLOC）1.047

②面向FP的估算模型

a．Albrecht ＆ Gaffney模型

E=-13.39+0.0545FP

b．Maston，Barnett和Mellichamp模型

E=585.7+15.12FP

2．动态多变量模型

①定义

动态多变量模型（软件方程式）是根据从4000多个当代软件项目中收集的生产率数据推导出来的。该模型把工作量看作软件规模和开发时间这两个变量的函数。

②形式

动态多变量估算模型的形式如下：

其中，E是以人月或人年为单位的工作量；t是以月或年为单位的项目持续时间；B是特殊技术因子，对于较小的程序（KLOC=5～15），B=0.16，对于超过70 KLOC的程序，B=0.39；P是生产率参数，它反映了以下因素对工作量的影响：

a．总体过程成熟度及管理水平。

b．使用良好的软件工程实践的程度。

c．使用的程序设计语言的级别。

d．软件环境的状态。

e．软件项目组的技术及经验。

f．应用系统的复杂程度。

3.COCOMO2模型

（1）3层模型

COCOMO是构造性成本模型（constructive cost model）的英文缩写。COCOMO2给出了3个层次模型，这3个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。这3个模型如下：

①应用系统组成模型：主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。

②早期设计模型：适用于体系结构设计阶段。

③体系结构模型：适用于完成体系结构设计之后的软件开发阶段。

（2）特点

①这个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。

②这些模型既可以用于不同类型的项目，也可以用于同一个项目的不同开发阶段。

（3）形式

COCOMO2模型把软件开发工作量表示成代码行数（KLOC）的非线性函数：

其中：E是开发工作量（以人月为单位）；a是模型系数；KLOC是估计的源代码行数（以千行为单位）；b是模型指数；fi（i=1～17）是成本因素。

（4）与COCOMO模型所使用成本因素的区别

①新增加了4个成本因素，它们分别要求的是可重用性、需要的文档量、人员连续性和多地点开发。

②略去了原始模型中的两个成本因素。

③某些成本因素（分析员能力、平台经验、语言和工具经验）对生产率的影响增加了，另一些成本因素（程序员能力）的影响减小了。

（5）模型指数

COCOMO2采用了的b分级模型，是使用5个分级因素Wi（1≤i≤5），其中每个因素都划分成从甚低（Wi=5）到特高（wi=0）的6个级别，用下式计算b（1.01～1.26）的数值：

（6）COCOMO2的5个分级因素

①项目先例性：指出对于开发组织来说该项目的新奇程度。

②开发灵活性：反映出为实现预先确定的外部接口和为了及早开发出产品而增加的工作量。

③风险排除度：反映了重大风险已被消除的比例。

④项目组凝聚力：表明了开发人员相互协作时可能存在的困难。

⑤过程成熟度：反映了按照能力成熟度模型度量出的项目组织的过程成熟度。

四、进度计划

1．相关概念

（1）任务集合

一个有效的软件过程应该定义一个适用于当前项目的任务集合。一个任务集合包括一组软件工程工作任务、里程碑和可交付的产品。为一个项目所定义的任务集合，必须包括为获得高质量的软件产品而应该完成的所有任务，但是同时又不能让项目组承担不必要的工作。

（2）项目管理者的工作

①目标

定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，保证及时发现拖延进度的情况。

②方法

管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。

（3）进度安排

①定义

软件项目的进度安排通过把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工作量分布于计划好的项目持续期内。进度计划将随着时间的流逝而不断演化。

②流程

a．在项目计划的早期，制定一个宏观的进度安排表，标识出主要的软件工程活动和这些活动影响到的产品功能。

b．随着项目的进展，把宏观进度表中的每个条目都精化成一个详细进度表，标识出完成一个活动所必须实现的一组特定任务，并安排好实现这些任务的进度。

2．估算开发时间

（1）利用成本估算模型估算开发时间

①Walston_Felix模型：

T=2.5E0.35

②原始的COCOMO模型：

T=2.5E0.38

③COCOMO2模型：

T=3.0E0.33+0.2×（b-1.01）

④Putnam模型：

T=2.4E1/3

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

（2）特殊情况

①描述

随着开发小组规模的扩大，个人生产率将下降，以致开发时间与从事开发工作的人数并不成反比关系。

②原因

a．小组变得更大时，每个人需要用更多时间与组内其他成员讨论问题、协调工作，因此增加了通信开销。

b．如果在开发过程中增加小组人员，最初一段时间内项目组总生产率不仅不会提高反而会下降。因为新成员在开始时不是生产力，且在他们学习期间需花费小组其他成员的时间。

c．Brooks规律

向一个已经延期的项目增加人力，只会使得它更加延期。

（3）项目组规模与项目组总生产率的关系

①通信路径

项目组成员之间的通信路径数，由项目组人数和项目组结构决定。通信路径数大约在P～P2/2的范围内变化。

②平均生产力

某一个组员与其他组员通信的路径数在1～（P-1）的范围内变化。如果不与任何人通信时个人生产率为L，而且每条通信路径导致生产率减少1，则组员个人平均生产率为：

Lr=L-1（P-1）r

其中，r是对通信路径数的度量，o<r≤l。

③总生产率

对于一个规模为P的项目组，项目组的总生产率为：

Ltot=P（L-l（P-1）r） 

对于给定的一组L，1和r的值，总生产率Ltot是项目组规模P的函数。存在一个最佳的项目组规模Popt这个规模的项目组其总生产率最高。

3.Gantt图

（1）例子

【例题】假设有一座陈旧的矩形木板房需要重新油漆。这项工作必须分3步完成：首先刮掉旧漆，然后刷上新漆，最后清除溅在窗户上的油漆。假设一共分配了15名工人去完成这项工作，然而工具却很有限：只有5把刮旧漆用的刮板，5把刷漆用的刷子，5把清除溅在窗户上的油漆用的小刮刀。怎样安排才能使工作进行得更有效呢？

【解析】每道工序需要的时间如表13-3所示。

表13-3 各道工序估计需用的时间（小时）

可以使用图13-1中Gantt图描绘上述流水作业过程：

①在时间为零时开始刮第1面墙上的旧漆；

②两小时后刮旧漆的工人转去刮第2面墙，同时另5名工人开始给第1面墙刷新漆；

③当给一面墙刷完新漆之后，第3组的5名工人立即清除溅在这面墙窗户上的漆。

图13-1 旧木板房刷漆丁程的Gantt图

从图13-1可以看出，12小时后刮完所有旧漆，20小时后完成所有墙壁的刷漆工作，再过2小时后清理工作结束。因此全部工程在22小时后结束。

（2）优点

①很形象地描绘任务分解情况，以及每个子任务（作业）的开始时间和结束时间。

②容易掌握、容易绘制。

（3）缺点

①不能显式地描绘各项作业彼此间的依赖关系。

②进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象。

③计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。

4．工程网络

（1）定义

工程网络可以描绘任务分解情况以及每项作业的开始时间和结束时间，它还显式地描绘各个作业彼此间的依赖关系。

（2）表示

图13-2 工程网络

工程网路，如图13-2所示。

①用箭头表示作业，作业通常既消耗资源又需要持续一定时间。

②用圆圈表示事件（开始或结束），事件是明确定义的时间点，并不消耗时间和资源。

③用虚线箭头表示虚拟作业，虚拟作业是为了显式地表示作业之间的依赖关系。

5．估算工程进度

（1）完善工程网络

图13-3 旧木板房刷漆工程的完整的工程网络

（粗线箭头是关键路径）

①把每个作业估计需要使用的时间写在表示该项作业的箭头上方。

②为每个事件计算最早时刻EET和最迟时刻LET，分别写在表示事件的圆圈的右上角和右下角，如图13-3左下角的符号所示。

（2）最早时刻EET

①定义

事件的最早时刻是该事件可以发生的最早时间。通常工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。

②计算规则

a．考虑进入该事件的所有作业。

b．对于每个作业都计算它的持续时间与起始事件的EET之和。

c．选取上述和数中的最大值作为该事件的最早时刻EET。

（3）最迟时刻LET

①定义

事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻。最后一个事件的最迟时刻就是它的最早时刻。其他事件的最迟时刻在工程网络上从右至左按逆作业流的方向计算。

②计算规则

a．考虑离开该事件的所有作业。

b．从每个作业的结束事件的最迟时刻中减去该作业的持续时间。

c．选取上述差数中的最小值作为该事件的最迟时刻LET。

6．关键路径

（1）定义

由最早时刻和最迟时刻相同的事件定义了关键路径，如图13-3所示。关键事件必须准时发生，组成关键作业的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。

（2）特点

①处于关键路径之外的任务进度拖后，不会影响整个项目的完成时间。

②处于关键路径之中的任务进度拖后，则整个项目的完成日期就会拖后。

7．机动时间

（1）定义

不在关键路径上的作业有一定程度的机动余地一实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些，而并不影响工程的结束时间。

（2）计算

一个作业可以有的全部机动时间等于它的结束事件的最迟时刻减去它的开始事件的最早时刻，再减去这个作业的持续时间：

机动时间=（LET）结束-（EET）开始-持续时间

（3）表示

工程网络中每个作业的机动时间写在该项作业的箭头下面的括号里，如图l3-3所示。在制定进度计划时仔细考虑和利用工程网络中的机动时间，往往能够安排出既节省资源又不影响最终竣工时间的进度表。

五、人员组织

1．必要性

（1）项目成功的关键合理的组织人员，使他们有效地分工协作共同完成开发工作。

（2）项目组组织得越好，其生产率越高，而且产品质量也越好。

（3）项目组具有了凝聚力，成功的可能性就大大增加了。

2．典型的组织方式

现有的软件项目组的组织方式很多，通常，组织软件开发人员的方法，取决于所承担的项目的特点、以往的组织经验以及管理者的看法和爱好，主要有3种典型的组织方式。

（1）民主制程序员组

①定义

民主制程序员组中小组成员完全平等，享有充分民主，通过协商做出技术决策。即小组成员之间的通信是平行的，如果小组内有n个成员，则可能的通信信道共有n（n-1）/2条。

②要求

a．小组的人数不能太多（2～8名成员为宜）

小组规模小，可以减少通信问题、容易确定小组的质量标准、用民主方式确定的标准更容易被大家遵守、组员间关系密切、能够互相学习。

b．采用非正式的组织方式

名义上有一个组长，但是他和组内其他成员完成同样的任务。在这样的小组中，由全体讨论协商决定应该完成的工作，并且根据每个人的能力和经验分配适当的任务。

③优点

a．组员们对发现程序错误持积极的态度，有助于更快速地发现错误，提高代码质量。

b．组员们享有充分民主，小组凝聚力高、学术空气浓厚，有利于攻克技术难关。

④缺点

没有明确的权威指导开发过程，组员间将缺乏必要的协调，最终可能导致工程失败。

⑤适用性

所要开发的软件的技术难度较高时，采用民主制程序员组是适宜的。

（2）主程序员组

①定义

图13-4 主程序员组的结构

主程序员组用经验多、技术好、能力强的程序员作为主程序员，同时，利用人和计算机在事务性工作方面给主程序员提供充分支持，而且所有通信都通过一两个人进行。典型的主程序员组的组织形式如图13-4所示。

②核心人员及其分工

a．主程序员

既是成功的管理人员又是经验丰富、技术好、能力强的高级程序员，负责体系结构设计和关键部分的详细设计，并且负责指导其他程序员完成详细设计和编码工作。

b．后备程序员

技术熟练而且富于经验，协助主程序员工作并且在必要时接替主程序员的工作。具体工作是设计测试方案、分析测试结果及独立于设计过程的其他工作。

c．编程秘书

负责完成与项目有关的全部事务性工作。

注意：图13-4介绍的是20世纪70年代初期的主程序员组组织结构，现在的情况已经和当时大不相同了，程序员已经有了自己的终端或工作站，他们自己完成代码的输入、编辑、编译、链接和调试等工作，无须由编程秘书统一做这些工作。

③特点（优点）

a．专业化：该组每名成员仅完成他们擅长的工作。

b．层次性：主程序员指挥组员工作，并对项目全面负责

④缺点

符合主程序员、后备程序员、编辑秘书标准的人才在现实社会中并不容易雇佣到。

⑤适用性

采用主程序员组这种组织方式的程序一般具有以下几方面的特点：

a．软件开发人员多数比较缺乏经验。

b．程序设计过程中有许多事务性的工作。

c．多渠道通信很费时间，将降低程序员的生产率。

（3）现代程序员组

①主程序员由两个人共同担任

图13-5 现代程序员组的结构

组织结构如图13-5所示。

a．技术负责人

负责小组的技术活动，参与全部代码审查工作，并且对代码的各方面质量负责。

b．行政负责人

负责非技术性事务的管理决策。不参与代码审查，其职责是对程序员的业绩进行评价。

②制定针对公共职责范围内的事务的处理方案

③实行分组策略

图13-6 大型项目的技术管理组织结构

采用分组策略，如图13-6所示。产品开发作为一个整体是在项目经理的指导下进行的，程序员向他们的组长汇报工作，而组长则向项目经理汇报工作。当产品规模更大时，可以适当增加中间管理层次。

④分散决定

图13-7 包含分散决策的组织方式

在合适的地方采用分散做决定的方法，如图13-7所示。这样做有利于形成畅通的通信渠道，以便充分发挥每个程序员的积极性和主动性，集思广益攻克技术难关。

六、质量保证

1．软件质量

（1）定义

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

（2）特点

①软件需求是度量软件质量的基础，与需求不一致就是质量不高。

②指定的开发标准定义了指导软件开发准则，没有遵守这些准则，会导致软件质量不高。

③软件满足明确描述的需求，但不满足隐含的需求，那么软件的质量是值得怀疑的。

（3）软件质量因素与产品活动

①软件质量因素

如表13-4所示，列出了软件质量因素的简明定义。

表13-4 软件质量因素的定义

②产品活动

可以把产品活动（倾向）分为产品运行、产品修改和产品转移。

③关系

软件质量因素和3种产品活动（倾向）之间的关系，如图13-8所示。

图13-8 软件质量因素与产品活动的关系

2．软件质量保证措施

（1）措施

①基于非执行的测试（复审或评审）：主要用来保证在编码前各阶段产生的文档的质量。

②基于执行的测试（软件测试）：在程序编写完后进行， 保证软件质量的最后一道防线。

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

（2）参加软件质量保证的人员分类

①软件工程师：用先进的技术方法和度量，进行复审以及完成软件测试来保证软件质量。

②SQA小组：辅助软件工程师以获得高质量的软件产品。其从事的软件质量保证活动的主要是：计划，监督，记录，分析和报告，它通过确保软件过程的质量来保证软件产品的质量。

（3）技术复审

正式技术复审的优点是能较早发现软件错误，防止错误被传播到软件过程的后续阶段。包括走查和审查等具体方法。

①走查

a．走查组

走查组由4～6名成员组成。成员包括负责起草文档的人、负责该文档说明的管理员、客户代表、下阶段开发组的代表、SQA小组的代表（作为组长）。

b．要点

第一，为了能发现重大错误，走查组成员最好是经验丰富的高级技术人员。

第二，走查组成员应根据材料并列出不理解的术语和认为不正确的术语。

第三，走查组组长引导该组成员走查文档，力求发现尽可能多的错误。

第四，走查的时间最长不要超过2小时。

c．方式

第一，参与者驱动法

参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须回答每个质疑。

第二，文档驱动法（更有效）

文档编写者向走查组成员仔细解释文档。走查组成员在此过程中针对事先准备好的问题或解释过程中发现的问题提出质疑。

②审查

a．审查组

查组由4人组成，分别是组长（既是管理人员又是技术负责人）、负责当前阶段开发工作的项目组代表、负责下一阶段开发工作的项目组代表、SQA小组的代表。

b．步骤

第一，综述

由负责编写文档的成员向审查组综述该文档。

第二，准备

评审员仔细阅读文档。

第三，审查

评审组仔细走查整个文档。

第四，返工

文档的作者负责解决在审查报告中列出的所有错误及问题。

第五，跟踪

组长必须确保所提出的每个问题都得到了圆满的解决。

c．与走查比较

第一，审查过程步数比走查多。

第二，审查过程每个步骤都是正规的仔细划分错误类型，并把这些信息运用在后续阶段的文档审查中以及未来产品的审查中。

d．重要性

审查是检测软件错误的一种好方法，利用审查可以在软件过程的早期阶段（修改成本低的阶段）发现并改正错误，即审查是一种经济有效的错误检测方法。

注意：走查的步骤比审查少，没有审查正规。

（4）程序正确性证明

①定义

正确性证明的基本思想是证明程序能完成预定的功能。应提供对程序功能的严格数学说明，然后根据程序代码证明程序确实能实现它的功能说明。

②方法

a．人工证明程序正确性

对于评价小程序可能有些价值，但在证明大型软件的正确性时，不仅工作量太大，而且在证明的过程中很容易包含错误。

b．自动系统

七、软件配置管理

1．相关概念

（1）定义

软件配置管理是在软件的整个生命期内管理变化的一组活动。其主要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告。

（2）目的

软件配置管理不同于软件维护，它的目标是使变化更正确且更容易被适应，在必须变化时减少所需花费的工作量。具体如下：

①标识变化；

②控制变化；

③确保适当地实现了变化；

④向需要知道这类信息的人报告变化。

（3）与维护的区别

维护是在软件交付给用户使用后才发生的，而配置管理是在软件项目启动时就开始，并且一直持续到软件退役后才终止的一组跟踪和控制活动。

2．软件配置

（1）软件配置项

软件过程的输出信息可以分为3类：

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

②描述计算机程序的文档（供技术人员或用户使用）。

③数据（程序内包含的或在程序外的）。

（2）基线

①定义

基线是已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它，即基线就是通过了正式复审的软件配置项。

②作用

基线有助于人们在不严重妨碍合理变化的前提下来控制变化。

（3）软件工具

把特定版本的编辑器、编译器和其他CASE工具，作为软件配置的一部分。为防止不同版本的工具产生结果不同，应把软件工具也基线化，并且列入到综合的配置管理过程之中。

3．软件配置管理过程

软件配置管理是软件质量保证的重要一环，它的主要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告，具体来说，软件配置管理主要有5项任务：标识、版本控制、变化控制、配置审计和报告。

（1）标识软件配置中的对象

①对象分类

a．基本对象：是软件工程师在分析、设计、编码或测试过程中创建出来的“文本单元”。

b．聚集对象：是基本对象和其他聚集对象的集合。

②要点

a．每个对象都有一组能唯一地标识它的特征：名字、描述、资源表和实现。

b．对象名是无二义性地标识该对象的一个字符串。

c．标识模式必须能无歧义地标识每个对象的不同版本。

（2）版本控制

①定义

版本控制使用规程和工具，以管理在软件工程过程中所创建的配置对象的不同版本。

②目标

借助于版本控制技术，用户能通过选择适当的版本来指定软件系统的配置。

③步骤

a．把属性和软件的每个版本关联起来。

b．描述一组所期望的属性（施加到系统上的功能变化的具体类型）来指定和构造所需要的配置。

（3）变化控制

①定义

变化控制把人的规程和自动工具结合起来，以提供一个控制变化的机制。

②过程

a．评估该变化在技术方面的得失、可能产生的副作用、对其他配置对象和系统功能的整体影响以及估算出的修改成本。

b．根据评估结果形成变化报告，供变化控制审批者审阅。

c．为每个被批准的变化都生成一个工程变化命令，描述将要实现的变化，必须遵守的约束以及复审和审计的标准。

d．把要修改的对象从项目数据库中提取出来，进行修改并应用适当的SQA活动。

e．把修改后的对象提交进数据库，用适当的版本控制机制创建该软件的下一个版本。

③主要功能

a．访问控制：决定哪个软件工程师有权访问和修改一个特定的配置对象。

b．同步控制：助于保证由两名不同的软件工程师完成的并行修改不会相互覆盖。

（4）配置审计

①正式的技术复审

正式的技术复审关注被修改后的配置对象的技术正确性。复审者审查该对象以确定它与其他软件配置项的一致性，并检查是否有遗漏或副作用。

②软件配置审计

软件配置审计通过评估配置对象的那些通常不在复审过程中考虑的特征，而成为对正式技术复审的补充。

（5）状态报告

①内容

a．发生的事件。

b．做的这件事的人。

c．事件是发生的时间。

d．产生的影响。

②作用

配置状态报告对大型软件开发项目的成功有重大贡献。配置状态报告通过改善所有相关人员之间的通信，帮助消除由于通信不精确、不及时所产生的严重问题。

八、能力成熟度模型

1．能力成熟度模型（CMM）

（1）定义

能力成熟度模型（CMM）是用于评价软件机构的软件过程能力成熟度的模型。

（2）目的

①为大型软件项目的招投标活动提供一种全面而客观的评审依据。

②应用于许多软件机构内部的过程改进活动中。

（3）基本思想

能力成熟度模型的基本思想是，由于问题是由人们管理软件过程的方法不当引起的，所以新软件技术的运用并不会自动提高软件的生产率和质量。

（4）作用

能力成熟度模型有助于软件开发机构建立一个有规律的、成熟的软件过程。改进后的软件过程将开发出质量更好的软件，使更多的软件项目免受时间延误和费用超支之苦。

（5）CMM在改进软件过程中所起的作用

①指导软件机构通过确定当前的过程成熟度并识别出对过程改进起关键作用的问题，明确过程改进的方向和策略。

②通过集中开展与过程改进的方向和策略相一致的一组过程改进活动，软件机构便能稳步而有效地改进其软件过程，使其软件过程能力得到循序渐进的提高。

（6）对能力成熟度划分的原因

①对软件过程的改进，是在完成一个又一个小的改进步骤基础上不断进行的渐进过程。

②这5个成熟度等级定义了一个有序的尺度，用以测量软件机构的软件过程成熟度和评价其软件过程能力，这些等级还帮助软件机构把应做的改进工作排出优先次序。

③成熟度等级是妥善定义的向成熟软件机构前进途中的平台，每个成熟度等级都为软件过程的继续改进提供了一个台阶。

2．能力成熟度的5个等级

（1）内容

①反映出软件机构为了达到从无序的、混乱的软件过程进化到有序的、有纪律的且成熟的软件过程的目的，必须经历的过程改进活动的途径。

②每个成熟度级别都是该软件机构沿着改进其过程的途径前进途中的一个台阶，后一个成熟度级别是前一个级别的软件过程的进化目标。

③每个成熟度级别中都包含一组过程改进的目标，满足这些目标后一个机构的软件过程就从当前级别进化到下一个成熟度级别。

（2）5个级别

①初始级（1级）

软件过程能力是不可预测的，其软件过程是不稳定的，产品质量只能根据相关人员的个人工作能力来预测。

②可重复级（2级）

软件项目的策划和跟踪是稳定的，已经为一个有纪律的管理过程提供了可重复以前成功实践的项目环境。

③已定义级（3级）

无论是管理活动还是工程活动都是稳定的。软件开发的成本和进度以及产品的功能和质量都受到控制，而且软件产品的质量具有可追溯性。

④已管理级（4级）

软件机构对软件过程和软件产品都建立了定量的质量目标，所有项目的重要的过程活动都是可度量的，软件过程在可度量的范围内运行。

⑤优化级（5级）

软件机构能够不断地改进其过程能力，既对现行的过程实例不断地改进和优化，又借助于新技术和新方法来实现未来的过程改进。这一级的软件机构是一个以防止出现缺陷为目标的机构，它有能力识别软件过程要素的薄弱环节，并有足够的手段改进它们。