141.软件项目管理

第13章  软件项目管理

与开发过程并行，一个是技术路线，一个是管理路线

在经历了若干个大型软件工程项目的失败以后，人们才逐渐认识到软件项目管理的重要性和特殊性。事实上，这些项目的失败并非因为从事软件开发工做的软件工程师无能，正相反，他们之中的绝大多数是当时杰出的技术专家。这些工程项目的失败主要是由于管理不善。

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

软件项目管理先于任何技术活动以前开始，而且贯穿于软件的整个生命周期之中。

软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工做量估算和完成期限估算。为了估算项目的工做量和完成期限，首先须要估算软件的规模。

 

13.1  估算软件规模  

13.1.1  代码行技术

代码行技术是比较简单的定量估算软件规模的方法。这种方法依据以往开发相似产品的经验和历史数据，估计实现一个功能所须要的源程序行数。当有以往开发相似产品的历史数据可供参考时，用这种方法估计出的数值仍是比较准确的。把实现每一个功能所须要的源程序行数累加起来，就可获得实现整个软件所须要的源程序行数。

 

为了使得对程序规模的估计值更接近实际值，能够由多名有经验的软件工程师分别作出估计。每一个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出这3种规模的平均值,和以后，再用下式计算程序规模的估计值：

L=        (13.1)

用代码行技术估算软件规模时，当程序较小时经常使用的单位是代码行数（LOC），当程序较大时经常使用的单位是千行代码数（KLOC）。

 

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

 

13.1.2  功能点技术

功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP）为单位度量软件规模。

1. 信息域特性

功能点技术定义了信息域的5个特性，分别是输入项数(Inp)、输出项数(Out)、查询数(Inq)、主文件数(Maf)和外部接口数(Inf)。下面讲述这5个特性的含义。

（1） 输入项数：  用户向软件输入的项数，这些输入给软件提供面向应用的数据。输入不一样于查询，后者单独计数，不计入输入项数中。

（2） 输出项数：  软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和出错信息等。报表内的数据项不单独计数。

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

（4） 主文件数：  逻辑主文件（即数据的一个逻辑组合，它多是大型数据库的一部分或是一个独立的文件）的数目。

（5） 外部接口数：  机器可读的所有接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另外一个系统。

 

2. 估算功能点的步骤

用下述3个步骤，可估算出一个软件的功能点数（即软件规模）。

（1） 计算未调整的功能点数UFP

首先，把产品信息域的每一个特性(即Inp、Out、Inq、Maf和Inf)都分类为简单级、平均级或复杂级，并根据其等级为每一个特性分配一个功能点数（例如，一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，而一个复杂级的输入项分配6个功能点）。

而后，用下式计算未调整的功能点数UFP： UFP=a₁×Inp+a₂×Out+a₃×Inq+a₄×Maf+a₅×Inf

其中，a_i(1≤i≤5)是信息域特性系数，其值由相应特性的复杂级别决定，如表13.1（见书297页）所示。

(2) 计算技术复杂性因子TCF

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

 DI=

技术复杂性因子TCF由下式计算：

TCF=0.65+0.01×DI

由于DI的值在0~70之间，因此TCF的值在0.65~1.35之间。

（3） 计算功能点数FP

用下式计算功能点数FP：

FP=UFP×TCF

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

 

13.2  工做量估算

软件估算模型使用由经验导出的公式来预测软件开发工做量，工做量是软件规模（KLOC或FP）的函数，工做量的单位一般是人月（pm)。

支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，所以，没有一个估算模型能够适用于全部类型的软件和开发环境。

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

 

2. 面向FP的估算模型

(1) Albrecht & Gaffney模型

E=-13.39+0.0545FP

(2) Maston,Barnett和Mellichamp模型

E=585.7+15.12FP

 

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

 

13.2.2  动态多变量模型

动态多变量模型也称为软件方程式，它是根据从4000多个当代软件项目中收集的生产率数据推导出来的。该模型把工做量看做是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式以下：

E=(LOC×B^0.333/P)³×(1/t)⁴          (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.2.3  COCOMO2模型

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

 

COCOMO2给出了3个层次的软件开发工做量估算模型，这3个层次的模型在估算工做量时，对软件细节考虑的详尽程度逐级增长。这些模型既能够用于不一样类型的项目，也能够用于同一个项目的不一样开发阶段。这3个层次的估算模型分别是：

（1） 应用系统组成模型。这个模型主要用于估算构建原型的工做量，模型名字暗示在构建原型时大量使用已有的构件。

（2） 早期设计模型。这个模型适用于体系结构设计阶段。

（3） 后体系结构模型。这个模型适用于完成体系结构设计以后的软件开发阶段。

 

下面之后体系结构模型为例，介绍COCOMO2模型。该模型把软件开发工做量表示成代码行数（KLOC）的非线性函数：

 E=       (13.3)

其中，

E是开发工做量（以人月为单位），

a是模型系数，

KLOC是估计的源代码行数（以千行为单位），

b是模型指数，

f_i(i=1~17)是成本因素。

 

每一个成本因素都根据它的重要程度和对工做量影响大小被赋予必定数值（称为工做量系数）。这些成本因素对任何一个项目的开发工做量都有影响，即便不使用COCOMO2模型估算工做量，也应该重视这些因素。Boehm把成本因素划分红产品因素、平台因素、人员因素和项目因素等4类。

表13.3（见书300页）列出了COCOMO2模型使用的成本因素及与之相联系的工做量系数。与原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述变化，这些变化反映了在过去十几年中软件行业取得的巨大进步。

 

（1） 新增长了4个成本因素，它们分别是要求的可重用性、须要的文档量、人员连续性（即人员稳定程度）和多地点开发。这个变化代表，这些因素对开发成本的影响日益增长。

（2） 略去了原始模型中的2个成本因素（计算机切换时间和使用现代程序设计实践）。如今，开发人员广泛使用工做站开发软件，批处理的切换时间已经再也不是问题。而“现代程序设计实践”已经发展成内容更普遍的“成熟的软件工程实践”的概念，而且在COCOMO2工做量方程的指数b中考虑了这个因素的影响。

（3） 某些成本因素（分析员能力、平台经验、语言和工具经验）对生产率的影响（即工做量系数最大值与最小值的比率）增长了，另外一些成本因素（程序员能力）的影响减少了。

为了肯定工做量方程中模型指数b的值，原始的COCOMO模型把软件开发项目划分红组织式、半独立式和嵌入式这样3种类型，并指定每种项目类型所对应的b值（分别是1.05，1.12和1.20）。COCOMO2采用了更加精细得多的b分级模型，这个模型使用5个分级因素Wi(1≤i≤5),其中每一个因素都划分红从甚低（Wi=5)到特高（Wi=0)的6个级别，而后用下式计算b的数值：

b=        (13.4)

所以，b的取值范围为1.01~1.26。显然，这种分级模式比原始COCOMO模型的分级模式更精细、更灵活。

 

COCOMO2使用的5个分级因素以下所述：

（1） 项目先例性。这个分级因素指出，对于开发组织来讲该项目的新奇程度。诸如开发相似系统的经验，须要创新体系结构和算法，以及须要并行开发硬件和软件等因素的影响，都体如今这个分级因素中。

（2） 开发灵活性。这个分级因素反映出，为了实现预先肯定的外部接口需求及为了及早开发出产品而须要增长的工做量。

（3） 风险排除度。这个分级因素反映了重大风险已被消除的比例。在多数状况下，这个比例和指定了重要模块接口（即选定了体系结构）的比例密切相关。

（4） 项目组凝聚力。这个分级因素代表了开发人员相互协做时可能存在的困难。这个因素反映了开发人员在目标和文化背景等方面相一致的程度，以及开发人员组成一个小组工做的经验。

（5） 过程成熟度。这个分级因素反映了按照能力成熟度模型（见13.7节）度量出的项目组织的过程成熟度。

在原始的COCOMO模型中，仅粗略地考虑了前两个分级因素对指数b之值的影响。

工做量方程中模型系数a的典型值为3.0，在实际工做中应该根据历史经验数据肯定一个适合本组织当前开发的项目类型的数值。

 

13.3  进度计划

不论从事哪一种技术性项目，实际状况都是，在实现一个大目标以前每每必须完成数以百计的小任务（也称为做业）。这些任务中有一些是处于“关键路径”（见13.3.5节）以外的，其完成时间若是没有严重拖后，就不会影响整个项目的完成时间；其余任务则处于关键路径之中，若是这些“关键任务”的进度拖后，则整个项目的完成日期就会拖后，管理人员应该高度关注关键任务的进展状况。

 

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

项目管理者的目标是定义所有项目任务，识别出关键任务，跟踪关键任务的进展情况，以保证能及时发现拖延进度的状况。为达到上述目标，管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。

 

软件项目的进度安排是这样一种活动，它经过把工做量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工做量分布于计划好的项目持续期内。进度计划将随着时间的流逝而不断演化。在项目计划的早期，首先制定一个宏观的进度安排表，标识出主要的软件工程活动和这些活动影响到的产品功能。随着项目的进展，把宏观进度表中的每一个条目都精化成一个详细进度表，从而标识出完成一个活动所必须实现的一组特定任务，并安排好了实现这些任务的进度。

13.3.1  估算开发时间

估算出完成给定项目所需的总工做量以后，接下来须要回答的问题就是：  用多长时间才能完成该项目的开发工做？对于一个估计工做量为20人月的项目，可能想出下列几种进度表：

1我的用20个月完成该项目；

4我的用5个月完成该项目；

20我的用1个月完成该项目。

可是，这些进度表并不现实，实际上软件开发时间与从事开发工做的人数之间并非简单的反比关系。

 

一般，成本估算模型也同时提供了估算开发时间T的方程。与工做量方程不一样，各类模型估算开发时间的方程很类似，例如：

(1) Walston_Felix模型

T=2.5E^0.35

(2) 原始的COCOMO模型

T=2.5E^0.38

(3) COCOMO2模型

T=3.0E^{0.33+0.2×(b-1.01)}

(4) Putnam模型

T=2.4E^1/3

 

其中，

E是开发工做量（以人月为单位），

T是开发时间（以月为单位）。

用上列方程计算出的T值，表明正常状况下的开发时间。客户每每但愿缩短软件开发时间，显然，为了缩短开发时间应该增长从事开发工做的人数。可是，经验告诉咱们，随着开发小组规模扩大，我的生产率将降低，以至开发时间与从事开发工做的人数并不成反比关系。出现这种现象主要有下述两个缘由：

 

当小组变得更大时，每一个人须要用更多时间与组内其余成员讨论问题、协调工做，所以增长了通讯开销。

若是在开发过程当中增长小组人员，则最初一段时间内项目组总生产率不只不会提升反而会降低。这是由于新成员在开始时不只不是生产力，并且在他们学习期间还须要花费小组其余成员的时间。

综合上述两个缘由，存在被称为Brooks规律的下述现象：  向一个已经延期的项目增长人力，只会使得它更加延期。

 

下面让咱们研究项目组规模与项目组总生产率的关系。

项目组成员之间的通讯路径数，由项目组人数和项目组结构决定。若是项目组共有P名组员，每一个组员必须与全部其余组员通讯以协调开发活动，则通讯路径数为P(P-1)/2。若是每一个组员只需与另一个组员通讯，则通讯路径数为P-1。通讯路径数少于P-1是不合理的，由于那将致使出现与任何人都没有联系的组员。

 

所以，通讯路径数大约在P~P²/2的范围内变化。也就是说，在一个层次结构的项目组中，通讯路径数为P^α，其中1<α<2。

对于某一个组员来讲，他与其余组员通讯的路径数在1~（P-1）的范围内变化。若是不与任何人通讯时我的生产率为L，并且每条通讯路径致使生产率减小l，则组员我的平均生产率为

Lr=L-l(P-1)^r             (13.5)

其中，r是对通讯路径数的度量，0<r≤1(假设至少有一名组员须要与一个以上的其余组员通讯，所以r>0)。

 

对于一个规模为P的项目组，从（13.5）式导出项目组的总生产率为

L_tot=P(L-l(P-1)^r)        (13.6)

对于给定的一组L，l和r的值，总生产率L_tot是项目组规模P的函数。随着P值增长，L_tot将从0增大到某个最大值，而后再降低。所以，存在一个最佳的项目组规模P_opt，这个规模的项目组其总生产率最高。

 

让咱们举例说明项目组规模与生产率的关系。假设我的最高生产率为500LOC/月（即L=500），每条通讯路径致使生产率降低10%（即l=50)。若是每一个组员都必须与组内全部其余组员通讯（r=1)，则项目组规模与生产率的关系列在表13.4（见书304页）中，可见，在这种状况下项目组的最佳规模是5.5人，即Popt=5.5。

事实上，作任何事情都须要时间，咱们不可能用“人力换时间”的办法无限缩短一个软件的开发时间。Boehm根据经验指出，软件项目的开发时间最多能够减小到正常开发时间的75%。若是要求一个软件系统的开发时间太短，则开发成功的几率几乎为零。

 

13.3.2  Gantt图

Gantt（甘特）图是历史悠久、应用普遍的制定进度计划的工具，下面经过一个很是简单的例子介绍这种工具。

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

 

一种作法是首先刮掉四面墙壁上的旧漆，而后给每面墙壁都刷上新漆，最后清除溅在每一个窗户上的油漆。显然这是效率最低的作法，由于总共有15名工人，然而每种工具却只有5件，这样安排工做在任什么时候候都有10名工人闲着没活干。

 

读者可能已经想到，应该采用“流水做业法”，也就是说，首先由5名工人用刮板刮掉第1面墙上的旧漆(这时其他10名工人休息)，当第1面墙刮净后，另外5名工人当即用刷子给这面墙刷新漆(与此同时拿刮板的5名工人转去刮第2面墙上的旧漆)，一旦刮旧漆的工人转到第3面墙并且刷新漆的工人转到第2面墙之后，余下的5名工人当即拿起刮刀去清除溅在第1面墙窗户上的油漆，……。这样安排每一个工人都有活干，所以可以在较短的时间内完成任务。

 

假设木板房的第二、4两面墙的长度比第一、3两面墙的长度长一倍，此外，不一样工做须要用的时间长短也不一样，刷新漆最费时间，其次是刮旧漆，清理(即清除溅在窗户上的油漆)须要的时间最少。表13.5（见书305页）列出了估计每道工序须要用的时间。能够使用图13.1中的Gantt图描绘上述流水做业过程： 在时间为零时开始刮第1面墙上的旧漆，两小时后刮旧漆的工人转去刮第2面墙，同时另5名工人开始给第1面墙刷新漆，每当给一面墙刷完新漆以后，第3组的5名工人当即清除溅在这面墙窗户上的漆。从图13.1能够看出12小时后刮完全部旧漆，20小时后完成全部墙壁的刷漆工做，再过2小时后清理工做结束。所以所有工程在22小时后结束，若是用前述的第一种作法，则须要36小时。

 

图13.1 旧木板房刷漆工程的Gantt图

 

13.3.3  工程网络

上一小节介绍的Gantt图能很形象地描绘任务分解状况，以及每一个子任务(做业)的开始时间和结束时间，所以是进度计划和进度管理的有力工具。它具备直观简明和容易掌握、容易绘制的优势，可是Gantt图也有3个主要缺点：

(1) 不能显式地描绘各项做业彼此间的依赖关系；

(2) 进度计划的关键部分不明确，难于断定哪些部分应当是主攻和主控的对象；

(3) 计划中有潜力的部分及潜力的大小不明确，每每形成潜力的浪费。

 

当把一个工程项目分解成许多子任务，而且它们彼此间的依赖关系又比较复杂时，仅仅用Gantt图做为安排进度的工具是不够的，不只难于作出既节省资源又保证进度的计划，并且还容易发生差错。

工程网络是制定进度计划时另外一种经常使用的图形工具，它一样能描绘任务分解状况以及每项做业的开始时间和结束时间，此外，它还显式地描绘各个做业彼此间的依赖关系。所以，工程网络是系统分析和系统设计的强有力的工具。

 

在工程网络中用箭头表示做业(例如，刮旧漆，刷新漆，清理等)，用圆圈表示事件(一项做业开始或结束)。注意，事件仅仅是能够明肯定义的时间点，它并不消耗时间和资源。做业一般既消耗资源又须要持续必定时间。图13.2是旧木板房刷漆工程的工程网络。图中表示刮第1面墙上旧漆的做业开始于事件1，结束于事件2。用开始事件和结束事件的编号标识一个做业，所以“刮第1面墙上旧漆”是做业1—2。

 

图13.2 旧木板房刷漆工程的工程网络

 

在工程网络中的一个事件，若是既有箭头进入又有箭头离开，则它既是某些做业的结束又是另外一些做业的开始。例如，图13.2中事件2既是做业1—2(刮第1面墙上的旧漆)的结束，又是做业2—3(刮第2面墙上旧漆)和做业2—4(给第1面墙刷新漆)的开始。也就是说，只有第1面墙上的旧漆刮完以后，才能开始刮第2面墙上旧漆和给第1面墙刷新漆这两个做业。所以，工程网络显式地表示了做业之间的依赖关系。

 

在图13.2中还有一些虚线箭头，它们表示虚拟做业，也就是事实上并不存在的做业。引入虚拟做业是为了显式地表示做业之间的依赖关系。例如，事件4既是给第1面墙刷新漆结束，又是给第2面墙刷新漆开始(做业4—6)。可是，在开始给第2面墙刷新漆以前，不只必须已经给第1面墙刷完了新漆，并且第2面墙上的旧漆也必须已经刮净(事件3)。也就是说，在事件3和事件4之间有依赖关系，或者说在做业2—3(刮第2面墙上旧漆)和做业4—6(给第2面墙刷新漆)之间有依赖关系，虚拟做业3—4明确地表示了这种依赖关系。注意，虚拟做业既不消耗资源也不须要时间。

 

13.3.4  估算工程进度

画出相似图13.2那样的工程网络以后，系统分析员就能够借助它的帮助估算工程进度了。为此须要在工程网络上增长一些必要的信息。

首先，把每一个做业估计须要使用的时间写在表示该项做业的箭头上方。注意，箭头长度和它表明的做业持续时间没有关系，箭头仅表示依赖关系，它上方的数字才表示做业的持续时间。

其次，为每一个事件计算下述两个统计数字： 最先时刻EET和最迟时刻LET。这两个数字将分别写在表示事件的圆圈的右上角和右下角，如图13.3左下角的符号所示。

事件的最先时刻是该事件能够发生的最先时间。一般工程网络中第一个事件的最先时刻定义为零，其余事件的最先时刻在工程网络上从左至右按事件发生顺序计算。计算最先时刻EET使用下述3条简单规则：

 

图13.3 旧木板房刷漆工程的完整的工程网络

 

(1) 考虑进入该事件的全部做业；

(2) 对于每一个做业都计算它的持续时间与起始事件的EET之和；

(3) 选取上述和数中的最大值做为该事件的最先时刻EET。

按照这种方法，不难沿着工程网络从左至右顺序算出每一个事件的最先时刻，计算结果标在图13.3的工程网络中(每一个圆圈内右上角的数字)。

 

事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚能够发生的时刻。按惯例，最后一个事件(工程结束)的最迟时刻就是它的最先时刻。其余事件的最迟时刻在工程网络上从右至左按逆做业流的方向计算。计算最迟时刻LET使用下述3条规则：

(1) 考虑离开该事件的全部做业；

(2) 从每一个做业的结束事件的最迟时刻中减去该做业的持续时间；

(3) 选取上述差数中的最小值做为该事件的最迟时刻LET。

图13.3中每一个圆圈内右下角的数字就是该事件的最迟时刻。

 

13.3.5  关键路径

图13.3中有几个事件的最先时刻和最迟时刻相同，这些事件定义了关键路径，在图中关键路径用粗线箭头表示。关键路径上的事件(关键事件)必须准时发生，组成关键路径的做业(关键做业)的实际持续时间不能超过估计的持续时间，不然工程就不能准时结束。

工程项目的管理人员应该密切注视关键做业的进展状况，若是关键事件出现的时间比预计的时间晚，则会使最终完成项目的时间拖后；若是但愿缩短工期，只有往关键做业中增长资源才会有效果。

 

13.3.6  机动时间

不在关键路径上的做业有必定程度的机动余地——实际开始时间能够比预约时间晚一些，或者实际持续时间能够比预约的持续时间长一些，而并不影响工程的结束时间。一个做业能够有的所有机动时间等于它的结束事件的最迟时刻减去它的开始事件的最先时刻，再减去这个做业的持续时间：

机动时间=(LET)_结束-(EET)_开始-持续时间

对于前述油漆旧木板房的例子，计算获得的非关键做业的机动时间列在表13.6（见书308页）中。

在工程网络中每一个做业的机动时间写在表明该项做业的箭头下面的括弧里(参看图13.3)。

在制定进度计划时仔细考虑和利用工程网络中的机动时间，每每可以安排出既节省资源又不影响最终竣工时间的进度表。在图13.4中的Gantt图描绘了其中的一种方案。

 

图13.4 旧木板房刷漆工程改进的Gantt图之一

 

这个简单例子明显说明了工程网络比Gantt图优越的地方： 它显式地定义事件及做业之间的依赖关系，Gantt图只能隐含地表示这种关系。可是Gantt图的形式比工程网络更简单更直观，为更多的人所熟悉，所以，应该同时使用这两种工具制订和管理进度计划，使它们互相补充取长补短。

 

以上经过旧木板房刷新漆工程的简单例子，介绍了制订进度计划的两个重要工具和方法。软件工程项目虽然比这个简单例子复杂得多，可是计划和管理的基本方法仍然是自顶向下分解，也就是把项目分解为若干个阶段，每一个阶段再分解成许多更小的任务，每一个任务又可进一步分解为若干个步骤等等。这些阶段、任务和步骤之间有复杂的依赖关系，所以，工程网络和Gantt图一样是安排进度和管理工程进展状况的强有力的工具。

 

第13.2节中介绍的工做量估计技术能够帮助咱们估计每项任务的工做量，根据人力分配状况，能够进一步肯定每项任务的持续时间。从这些基本数据出发，根据做业之间的依赖关系，利用工程网络和Gantt图能够制定出合理的进度计划，而且可以科学地管理软件开发工程的进展状况。

 

13.4  人员组织

软件项目成功的关键是有高素质的软件开发人员。然而大多数软件的规模都很大，单个软件开发人员没法在给按期限内完成开发工做，所以，必须把多名软件开发人员合理地组织起来，使他们有效地分工协做共同完成开发工做。

为了成功地完成软件开发工做，项目组成员必须以一种有意义且有效的方式彼此交互和通讯。如何组织项目组是一个重要的管理问题，管理者应该合理地组织项目组，使项目组有较高生产率，可以按预约的进度计划完成所承担的工做。经验代表，项目组组织得越好，其生产率越高，并且产品质量也越好。

除了追求更好的组织方式以外，每一个管理者的目标都是创建有凝聚力的项目组。一个有高度凝聚力的小组，由一批团结得很是紧密的人组成，他们的总体力量大于个体力量的总和。一旦项目组具备了凝聚力，成功的可能性就大大增长了。

现有的软件项目组的组织方式不少，一般，组织软件开发人员的方法，取决于所承担的项目的特色、以往的组织经验以及管理者的见解和喜爱。下面介绍3种典型的组织方式。

 

13.4.1  民主制程序员组

民主制程序员组的一个重要特色是，小组成员彻底平等，享有充分民主，经过协商作出技术决策。所以，小组成员之间的通讯是平行的，若是小组内有n个成员，则可能的通讯信道共有n(n-1)/2条。

程序设计小组的人数不能太多,不然组员间彼此通讯的时间将多于程序设计时间。此外,一般不能把一个软件系统划分红大量独立的单元,所以,若是程序设计小组人数太多,则每一个组员所负责开发的程序单元与系统其余部分的界面将是复杂的,不只出现接口错误的可能性增长,并且软件测试将既困难又费时间。

通常说来，程序设计小组的规模应该比较小,以2～8名成员为宜。若是项目规模很大,用一个小组不能在预约时间内完成开发任务,则应该使用多个程序设计小组,每一个小组承担工程项目的一部分任务，在必定程度上独立自主地完成各自的任务。系统的整体设计应该可以保证由各个小组负责开发的各部分之间的接口是良好定义的,而且是尽量简单的。

小组规模小,不只能够减小通讯问题,并且还有其余好处。例如,容易肯定小组的质量标准,并且用民主方式肯定的标准更容易被你们遵照;组员间关系密切,可以互相学习等等。

民主制程序员组一般采用非正式的组织方式，也就是说，虽然名义上有一个组长，可是他和组内其余成员完成一样的任务。在这样的小组中，由全体讨论协商决定应该完成的工做，而且根据每一个人的能力和经验分配适当的任务。

民主制程序员组的主要优势是，组员们对发现程序错误持积极的态度，这种态度有助于更快速地发现错误，从而致使高质量的代码。

民主制程序员组的另外一个优势是，组员们享有充分民主，小组有高度凝聚力，组内学术空气浓厚，有利于攻克技术难关。所以，当有难题须要解决时，也就是说，当所要开发的软件的技术难度较高时，采用民主制程序员组是适宜的。

若是组内多数成员是经验丰富技术熟练的程序员,那么上述非正式的组织方式可能会很是成功。在这样的小组内组员享有充分民主,经过协商,在自愿的基础上做出决定,所以可以加强团结、提升工做效率。可是,若是组内多数成员技术水平不高,或是缺少经验的新手,那么这种非正式的组织方式也有严重缺点： 因为没有明确的权威指导开发工程的进行,组员间将缺少必要的协调,最终可能致使工程失败。

为了使少数经验丰富、技术高超的程序员在软件开发过程当中可以发挥更大做用，程序设计小组也能够采用下一小节中介绍的另一种组织形式。

 

13.4.2  主程序员组

美国IBM公司在20世纪70年代初期开始采用主程序员组的组织方式。采用这种组织方式主要出于下述几点考虑：

(1) 软件开发人员多数比较缺少经验；

(2) 程序设计过程当中有许多事务性的工做，例如，大量信息的存储和更新；

(3) 多渠道通讯很费时间，将下降程序员的生产率。

 

主程序员组用经验多、技术好、能力强的程序员做为主程序员，同时，利用人和计算机在事务性工做方面给主程序员提供充分支持，并且全部通讯都经过一两我的进行。这种组织方式相似于外科手术小组的组织： 主刀大夫对手术全面负责，而且完成制订手术方案、开刀等关键工做，同时又有麻醉师、护士长等技术熟练的专门人员协助和配合他的工做。此外，必要时手术组还要请其余领域的专家（例如，心脏科医生或妇产科医生）协助。

 

上述比喻突出了主程序员组的两个重要特性：

（1） 专业化。该组每名成员仅完成他们受过专业训练的那些工做。

（2） 层次性。主刀大夫指挥每名组员工做，并对手术全面负责。

当时，典型的主程序员组的组织形式如图13.5所示。该组由主程序员、后备程序员、编程秘书以及1~3名程序员组成。在必要的时候，该组还有其余领域的专家协助。

 

图13.5 主程序员组的结构

 

主程序员组核心人员的分工以下所述：

（1） 主程序员既是成功的管理人员又是经验丰富、技术好、能力强的高级程序员，负责体系结构设计和关键部分（或复杂部分）的详细设计，而且负责指导其余程序员完成详细设计和编码工做。如图13.5所示，程序员之间没有通讯渠道，全部接口问题都由主程序员处理。主程序员对每行代码的质量负责，所以，他还要对组内其余成员的工做成果进行复查。

（2） 后备程序员也应该技术熟练并且富于经验，他协助主程序员工做而且在必要时（例如，主程序员生病、出差或“跳槽”）接替主程序员的工做。所以，后备程序员必须在各方面都和主程序员同样优秀，而且对本项目的了解也应该和主程序员同样深刻。平时，后备程序员的工做主要是，设计测试方案、分析测试结果及独立于设计过程的其余工做。

（3） 编程秘书负责完成与项目有关的所有事务性工做，例如，维护项目资料库和项目文档，编译、连接、执行源程序和测试用例。

注意，上面介绍的是20世纪70年代初期的主程序员组组织结构，如今的状况已经和当时大不相同了，程序员已经有了本身的终端或工做站，他们本身完成代码的输入、编辑、编译、连接和测试等工做，无须由编程秘书统一作这些工做。典型的主程序员组的现代形式将在下一小节介绍。

虽然图13.5所示的主程序员组的组织方式提及来有很多优势，可是，它在许多方面倒是不切实际的。

首先，如前所述，主程序员应该是高级程序员和优秀管理者的结合体。承担主程序员工做须要同时具有这两方面的才能，可是，在现实社会中这样的人才并很少见。一般，既缺少成功的管理者也缺少技术熟练的程序员。

其次，后备程序员更难找。人们指望后备程序员像主程序员同样优秀，可是，他们必须坐在“替补席”上，拿着较低的工资等待随时接替主程序员的工做。几乎没有一个高级程序员或高级管理人员愿意接受这样的工做。

第三，编程秘书也很难找到。专业的软件技术人员通常都厌烦平常的事务性工做，可是，人们却指望编程秘书成天只干这类工做。

咱们须要一种更合理、更现实的组织程序员组的方法，这种方法应该能充分结合民主制程序员组和主程序员组的优势，而且能用于实现更大规模的软件产品。

 

13.4.3  现代程序员组

民主制程序员组的一个主要优势，是小组成员都对发现程序错误持积极、主动的态度。可是，使用主程序员组的组织方式时，主程序员对每行代码的质量负责，所以，他必须参与全部代码审查工做。因为主程序员同时又是负责对小组成员进行评价的管理员，他参与代码审查工做就会把所发现的程序错误与小组成员的工做业绩联系起来，从而形成小组成员出现不肯意发现错误的心理。

 

解决上述问题的方法是，取消主程序员的大部分行政管理工做。前面已经指出，很难找到既是高度熟练的程序员又是成功的管理员的人，取消主程序员的行政管理工做，不只解决了小组成员不肯意发现程序错误的心理问题，也使得寻找主程序员的人选再也不那么困难。因而，实际的“主程序员”应该由两我的共同担任：  一个技术负责人，负责小组的技术活动；一个行政负责人，负责全部非技术性事务的管理决策。这样的组织结构如图13.6所示。技术组长天然要参与所有代码审查工做，由于他要对代码的各方面质量负责；相反，行政组长不能够参与代码审查工做，由于他的职责是对程序员的业绩进行评价。行政组长应该在常规调度会议上了解每名组员的技术能力和工做业绩。

 

图13.6 现代程序员组的结构

 

在开始工做以前明确划分技术组长和行政组长的管理权限是很重要的。可是，即便已经作了明确分工，有时也会出现职责不清的矛盾。例如，考虑年度休假问题，行政组长有权批准某个程序员休年假的申请，由于这是一个非技术性问题，可是技术组长可能立刻否决了这个申请，由于已经接近预约的项目结束日期，目前人手很是紧张。解决这类问题的办法是求助于更高层的管理人员，对行政组长和技术组长都认为是属于本身职责范围内的事务，制定一个处理方案。

因为程序员组成员人数不宜过多，当软件项目规模较大时，应该把程序员分红若干个小组，采用图13.7所示的组织结构。该图描绘的是技术管理组织结构，非技术管理组织结构与此相似。由图能够看出，产品开发做为一个总体是在项目经理的指导下进行的，程序员向他们的组长汇报工做，而组长则向项目经理汇报工做。当产品规模更大时，能够适当增长中间管理层次。

 

图13.7 大型项目的技术管理组织结构

 

把民主制程序员组和主程序员组的优势结合起来的另外一种方法，是在合适的地方采用分散作决定的方法，如图13.8所示。这样作有利于造成畅通的通讯渠道，以便充分发挥每一个程序员的积极性和主动性，集思广益攻克技术难关。这种组织方式对于适合采用民主方法的那类问题（例如，研究性项目或遇到技术难题须要用集体智慧攻关）很是有效。尽管这种组织方式适当地发扬了民主，可是上下级之间的箭头（即管理关系）仍然是向下的，也就是说，是在集中指导下发扬民主。显然，若是程序员能够指挥项目经理，则只会引发混乱。

 

图13.8 包含分散决策的组织方式

 

13.5  质量保证  

13.5.1  软件质量

归纳地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具备的隐含特征相一致的程度。上述定义强调了下述的3个要点：

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

（2） 指定的开发标准定义了一组指导软件开发的准则，若是没有遵照这些准则，几乎确定会致使软件质量不高。

（3） 一般，有一组没有显式描述的隐含需求（例如，软件应该是容易维护的）。若是软件知足明确描述的需求，但却不知足隐含的需求，那么软件的质量仍然是值得怀疑的。

虽然软件质量是难于定量度量的软件属性，可是仍然可以提出许多重要的软件质量指标(其中绝大多数目前还处于定性度量阶段)。

本节介绍影响软件质量的主要因素，这些因素是从管理角度对软件质量的度量。能够把这些质量因素分红3组，分别反映用户在使用软件产品时的3种不一样倾向或观点。这3种倾向是： 产品运行、产品修改和产品转移。图13.9描绘了软件质量因素和上述3种倾向(或产品活动)之间的关系，表13.7（见书315页）列出了软件质量因素的简明定义。

 

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

 

13.5.2  软件质量保证措施

软件质量保证（software quality assurance,SQA）的措施主要有：  基于非执行的测试（也称为复审或评审），基于执行的测试（即之前讲过的软件测试）和程序正确性证实。复审主要用来保证在编码以前各阶段产生的文档的质量；基于执行的测试须要在程序编写出来以后进行，它是保证软件质量的最后一道防线；程序正确性证实使用数学方法严格验证程序是否与对它的说明彻底一致。

 

参加软件质量保证工做的人员，能够划分红下述两类：

软件工程师经过采用先进的技术方法和度量，进行正式的技术复审以及完成计划周密的软件测试来保证软件质量。

SQA小组的职责，是辅助软件工程师以得到高质量的软件产品。其从事的软件质量保证活动主要是：  计划，监督，记录，分析和报告。简而言之，SQA小组的做用是，经过确保软件过程的质量来保证软件产品的质量。

 

1. 技术复审的必要性

正式技术复审的显著优势是，可以较早发现软件错误，从而可防止错误被传播到软件过程的后续阶段。

统计数字代表，在大型软件产品中检测出的错误，60%~70%属于规格说明错误或设计错误，而正式技术复审在发现规格说明错误和设计错误方面的有效性高达75%。因为可以检测出并排除掉绝大部分这类错误，复审可大大下降后续开发和维护阶段的成本。

实际上，正式技术复审是软件质量保证措施的一种，包括走查（walkthrough)和审查（inspection）等具体方法。走查的步骤比审查少，并且没有审查正规。

 

2. 走查

走查组由4~6名成员组成。以走查规格说明的小组为例，成员至少包括一名负责起草规格说明的人，一名负责该规格说明的管理员，一位客户表明，以及下阶段开发组（在本例中是设计组）的一名表明和SQA小组的一名表明。其中SQA小组的表明应该做为走查组的组长。

为了能发现重大错误，走查组成员最好是经验丰富的高级技术人员。必须把被走查的材料预先分发给走查组每位成员。走查组成员应该仔细研究材料并列出两张表：  一张表是他不理解的术语，另外一张是他认为不正确的术语。

走查组组长引导该组成员走查文档，力求发现尽量多的错误。走查组的任务仅仅是标记出错误而不是改正错误，改正错误的工做应该由该文档的编写组完成。走查的时间最长不要超过2小时，这段时间应该用来发现和标记错误，而不是改正错误。

走查主要有下述两种方式：

（1） 参与者驱动法。参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的表明必须回答每一个质疑，要么认可确实有错误，要么对质疑作出解释。

（2） 文档驱动法。文档编写者向走查组成员仔细解释文档。走查组成员在此过程当中不时针对事先准备好的问题或解释过程当中发现的问题提出质疑。这种方法可能比第一种方法更有效，每每能检测出更多错误。经验代表，使用文档驱动法时许多错误是由文档讲解者本身发现的。

 

3. 审查

审查的范围比走查普遍得多，它的步骤也比较多。一般，审查过程包括下述5个基本步骤：

（1） 综述。由负责编写文档的一名成员向审查组综述该文档。在综述会结束时把文档分发给每位与会者。

（2） 准备。评审员仔细阅读文档。最好列出在审查中发现的错误的类型，并按发生频率把错误类型分级，以辅助审查工做。这些列表有助于评审员们把注意力集中到最常发生错误的区域。

（3） 审查。评审组仔细走查整个文档。和走查同样，这一步的目的也是发现文档中的错误，而不是改正它们。一般每次审查会不超过90分钟。审查组组长应该在一天以内写出一份关于审查的报告。

（4） 返工。文档的做者负责解决在审查报告中列出的全部错误及问题。

（5） 跟踪。组长必须确保所提出的每一个问题都获得了圆满的解决（要么修正了文档，要么澄清了被误认为是错误的条目）。必须仔细检查对文档所作的每一个修正，以确保没有引入新的错误。若是在审查过程当中返工量超过5%，则应该由审查组再对文档全面地审查一遍。

 

一般，审查组由4人组成。组长既是审查组的管理人员又是技术负责人。审查组必须包括负责当前阶段开发工做的项目组表明和负责下一阶段开发工做的项目组表明，此外，还应该包括一名SQA小组的表明。

审查过程不只步数比走查多，并且每一个步骤都是正规的。审查的正规性体如今：  仔细划分错误类型，并把这些信息运用在后续阶段的文档审查中以及将来产品的审查中。

审查是检测软件错误的一种好方法，利用审查能够在软件过程的早期阶段发现并改正错误，也就是说，能在修正错误的代价变得很昂贵以前就发现并改正错误。所以，审查是一种经济有效的错误检测方法。

 

4. 程序正确性证实

测试能够暴露程序中的错误，所以是保证软件可靠性的重要手段；可是，测试只能证实程序中有错误，并不能证实程序中没有错误。所以，对于保证软件可靠性来讲，测试是一种不完善的技术，人们天然但愿研究出完善的正确性证实技术。一旦研究出实用的正确性证实程序(即，能自动证实其余程序的正确性的程序)，软件可靠性将更有保证，测试工做量将大大减小。可是，即便有了正确性证实程序，软件测试也仍然是须要的，由于程序正确性证实只证实程序功能是正确的，并不能证实程序的动态特性是符合要求的，此外，正确性证实过程自己也可能发生错误。

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

在20世纪60年代初期，人们已经开始研究程序正确性证实的技术，提出了许多不一样的技术方法。虽然这些技术方法自己很复杂，可是它们的基本原理倒是至关简单的。

若是在程序的若干个点上，设计者能够提出关于程序变量及它们的关系的断言，那么在每一点上的断言都应该永远是真的。假设在程序的P1,P2,…，Pn等点上的断言分别是a(1),a(2)，…，a(n)，其中a(1)必须是关于程序输入的断言，a(n)必须是关于程序输出的断言。

为了证实在点Pi和Pi+1之间的程序语句是正确的，必须证实执行这些语句以后将使断言a(i)变成a(i+1)。若是对程序内全部相邻点都能完成上述证实过程，则证实了输入断言加上程序能够导出输出断言。若是输入断言和输出断言是正确的，并且程序确实是能够终止的(不包含死循环)，则上述过程就证实了程序的正确性。

人工证实程序正确性，对于评价小程序可能有些价值，可是在证实大型软件的正确性时，不只工做量太大，更主要的是在证实的过程当中很容易包含错误，所以是不实用的。为了实用的目的，必须研究能证实程序正确性的自动系统。

目前已经研究出证实PASCAL和LISP程序正确性的程序系统，正在对这些系统进行评价和改进。如今这些系统还只能对较小的程序进行评价，毫无疑问还须要作许多工做，这样的系统才能实际用于大型程序的正确性证实。

 

 

13.6  软件配置管理

任何软件开发都是迭代过程，也就是说，在设计过程会发现需求说明书中的问题，在实现过程又会暴露出设计中的错误。此外，随着时间推移客户的需求也会或多或少发生变化。所以，在开发软件的过程当中，变化（或称为变更）既是必要的，又是不可避免的。可是，变化也很容易失去控制，若是不能适当地控制和管理变化，势必形成混乱并产生许多严重的错误。

软件配置管理是在软件的整个生命期内管理变化的一组活动。具体地说，这组活动用来： 

①标识变化； ②控制变化； ③确保适当地实现了变化； ④向须要知道这类信息的人报告变化。

软件配置管理不一样于软件维护。维护是在软件交付给用户使用后才发生的，而配置管理是在软件项目启动时就开始，而且一直持续到软件退役后才终止的一组跟踪和控制活动。
软件配置管理的目标是，使变化更正确且更容易被适应，在必须变化时减小所需花费的工做量。

13.6.1  软件配置

1. 软件配置项

软件过程的输出信息能够分为3类： 

①计算机程序（源代码和可执行程序）； ②描述计算机程序的文档（供技术人员或用户使用）； ③数据（程序内包含的或在程序外的）。 上述这些项组成了在软件过程当中产生的所有信息，咱们把它们统称为软件配置，而这些项就是软件配置项。

随着软件开发过程的进展，软件配置项的数量迅速增长。不幸的是，因为前述的种种缘由，软件配置项的内容随时均可能发生变化。为了开发出高质量的软件产品，软件开发人员不只要努力保证每一个软件配置项正确，并且必须保证一个软件的全部配置项是彻底一致的。

能够把软件配置管理看做是应用于整个软件过程的软件质量保证活动，是专门用于管理变化的软件质量保证活动。

 

2. 基线

基线是一个软件配置管理概念，它有助于咱们在不严重妨碍合理变化的前提下来控制变化。IEEE把基线定义为： 已经经过了正式复审的规格说明或中间产品，它能够做为进一步开发的基础，而且只有经过正式的变化控制过程才能改变它。
简而言之，基线就是经过了正式复审的软件配置项。在软件配置项变成基线以前，能够迅速而非正式地修改它。一旦创建了基线以后，虽然仍然能够实现变化，可是，必须应用特定的、正式的过程（称为规程）来评估、实现和验证每一个变化。
除了软件配置项以外，许多软件工程组织也把软件工具置于配置管理之下，也就是说，把特定版本的编辑器、编译器和其余CASE工具，做为软件配置的一部分“固定”下来。由于当修改软件配置项时必然要用到这些工具，为防止不一样版本的工具产生的结果不一样，应该把软件工具也基线化，而且列入到综合的配置管理过程之中。

 

13.6.2  软件配置管理过程

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

1. 标识软件配置中的对象

为了控制和管理软件配置项，必须单独命名每一个配置项，而后用面向对象方法组织它们。能够标识出两类对象：  基本对象和汇集对象（能够把汇集对象做为表明软件配置完整版本的一种机制）。基本对象是软件工程师在分析、设计、编码或测试过程当中建立出来的“文本单元”，例如，需求规格说明的一个段落、一个模块的源程序清单或一组测试用例。汇集对象是基本对象和其余汇集对象的集合。
每一个对象都有一组能唯一地标识它的特征：  名字、描述、资源表和“实现”。其中，对象名是无二义性地标识该对象的一个字符串。
在设计标识软件对象的模式时，必须认识到对象在整个生命周期中一直都在演化，所以，所设计的标识模式必须能无歧义地标识每一个对象的不一样版本。

2. 版本控制

版本控制联合使用规程和工具，以管理在软件工程过程当中所建立的配置对象的不一样版本。借助于版本控制技术，用户可以经过选择适当的版原本指定软件系统的配置。实现这个目标的方法是，把属性和软件的每一个版本关联起来，而后经过描述一组所指望的属性来指定和构造所须要的配置。
上面提到的“属性”，既能够简单到仅是赋给每一个配置对象的具体版本号，也能够复杂到是一个布尔变量串，其指明了施加到系统上的功能变化的具体类型。
非发行版本，只要变化的版本，每一版不能覆盖

3. 变化控制

对于大型软件开发项目来讲，无控制的变化将迅速致使混乱。变化控制把人的规程和自动工具结合起来，以提供一个控制变化的机制。典型的变化控制过程以下：  接到变化请求以后，首先评估该变化在技术方面的得失、可能产生的反作用、对其余配置对象和系统功能的总体影响以及估算出的修改为本。评估的结果造成“变化报告”，该报告供“变化控制审批者”审阅。所谓变化控制审批者既能够是一我的也能够由一组人组成，其对变化的状态和优先级作最终决策。

为每一个被批准的变化都生成一个“工程变化命令”，其描述将要实现的变化，必须遵照的约束以及复审和审计的标准。把要修改的对象从项目数据库中“提取（check out）”出来【给迁出项目对象加锁，其余人不能修改】，进行修改并应用适当的SQA活动。最后，把修改后的对象“提交（check in）”进数据库【解锁，其余人能够修改】，并用适当的版本控制机制建立该软件的下一个版本。
“提交”和“提取”过程实现了变化控制的两个主要功能——访问控制和同步控制。访问控制决定哪一个软件工程师有权访问和修改一个特定的配置对象，同步控制有助于保证由两名不一样的软件工程师完成的并行修改不会相互覆盖。

在一个软件配置项变成基线以前，仅需应用非正式的变化控制。该配置对象的开发者能够对它进行任何合理的修改（只要修改不会影响到开发者工做范围以外的系统需求）。一旦该对象通过了正式技术复审并得到批准，就建立了一个基线。而一旦一个软件配置项变成了基线，就开始实施项目级的变化控制。如今，为了进行修改开发者必须得到项目管理者的批准（若是变化是“局部的”），若是变化影响到其余软件配置项，还必须获得变化控制审批者的批准。在某些状况下，能够省略正式的变化请求、变化报告和工程变化命令，可是，必须评估每一个变化而且跟踪和复审全部变化。

4. 配置审计
为了确保适当地实现了所须要的变化，一般从下述两方面采起措施：  ①正式的技术复审； ②软件配置审计。
正式的技术复审（见13.5.2节）关注被修改后的配置对象的技术正确性。复审者审查该对象以肯定它与其余软件配置项的一致性，并检查是否有遗漏或反作用。

软件配置审计经过评估配置对象的那些一般不在复审过程当中考虑的特征（例如，修改时是否遵循了软件工程标准，是否在该配置项中显著地标明了所作的修改，是否注明了修改日期和修改者，是否适当地更新了全部相关的软件配置项，是否遵循了标注变化、记录变化和报告变化的规程），而成为对正式技术复审的补充。

 

5. 状态报告
书写配置状态报告是软件配置管理的一项任务，它回答下述问题：  ①发生了什么事？ ②谁作的这件事？③这件事是何时发生的？④它将影响哪些其余事物？
配置状态变化对大型软件开发项目的成功有重大影响。当大量人员在一块儿工做时，可能一我的并不知道另外一我的在作什么。两名开发人员可能试图按照相互冲突的想法去修改同一个软件配置项；软件工程队伍可能耗费几我的月的工做量根据过期的硬件规格说明开发软件；察觉到所建议的修改有严重反作用的人可能还不知道该项修改正在进行。配置状态报告经过改善全部相关人员之间的通讯，帮助消除这些问题。

 

13.7  能力成熟度模型

美国卡内基梅隆大学软件工程研究所在美国国防部资助下于20世纪80年代末创建的能力成熟度模型（capability maturity model，CMM)，是用于评价软件机构的软件过程能力成熟度的模型。最初，创建此模型的目的主要是，为大型软件项目的招投标活动提供一种全面而客观的评审依据，发展到后来，此模型又同时被应用于许多软件机构内部的过程改进活动中。

多年来，软件危机一直困扰着许多软件开发机构。很多人试图经过采用新的软件开发技术来解决在软件生产率和软件质量等方面存在的问题，但效果并不使人十分满意。上述事实促令人们进一步考察软件过程，从而发现关键问题在于对软件过程的管理不尽人意。事实证实，在无规则和混乱的管理之下，先进的技术和工具并不能发挥出应有的做用。人们逐渐认识到，改进对软件过程的管理是消除软件危机的突破口，不再能忽视在软件过程当中管理的关键做用了。

能力成熟度模型的基本思想是，因为问题是由咱们管理软件过程的方法不当引发的，因此新软件技术的运用并不会自动提升软件的生产率和质量。能力成熟度模型有助于软件开发机构创建一个有规律的、成熟的软件过程。改进后的软件过程将开发出质量更好的软件，使更多的软件项目免受时间和费用超支之苦。

软件过程包括各类活动、技术和工具，所以，它实际上既包括了软件开发的技术方面又包括了管理方面。CMM的策略是，力图改进对软件过程的管理，而在技术方面的改进是其必然的结果。
CMM在改进软件过程当中所起的做用主要是，指导软件机构经过肯定当前的过程成熟度并识别出对过程改进起关键做用的问题，从而明确过程改进的方向和策略。经过集中开展与过程改进的方向和策略相一致的一组过程改进活动，软件机构便能稳步而有效地改进其软件过程，使其软件过程能力获得按部就班的提升。

对软件过程的改进，是在完成一个又一个小的改进步骤基础上不断进行的渐进过程，而不是一蹴而就的完全革命。CMM把软件过程从无序到有序的进化过程分红5个阶段，并把这些阶段排序，造成5个逐层提升的等级。这5个成熟度等级定义了一个有序的尺度，用以测量软件机构的软件过程成熟度和评价其软件过程能力，这些等级还能帮助软件机构把应作的改进工做排出优先次序。成熟度等级是妥善定义的向成熟软件机构前进途中的平台，每一个成熟度等级都为软件过程的继续改进提供了一个台阶。

CMM对5个成熟度级别特性的描述，说明了不一样级别之间软件过程的主要变化。从“1级”到“5级”，反映出一个软件机构为了达到从一个无序的、混乱的软件过程进化到一种有序的、有纪律的且成熟的软件过程的目的，必须经历的过程改进活动的途径。每个成熟度级别都是该软件机构沿着改进其过程的途径前进途中的一个台阶，后一个成熟度级别是前一个级别的软件过程的进化目标。

CMM的每一个成熟度级别中都包含一组过程改进的目标，知足这些目标后一个机构的软件过程就从当前级别进化到下一个成熟度级别；每达到成熟度级别框架的下一个级别，该机构的软件过程都获得必定程度的完善和优化，也使得过程能力获得提升；随着成熟度级别的不断提升，该机构的过程改进活动取得了更加显著的成效，从而使软件过程获得进一步的完善和优化。CMM就是以上述方式支持软件机构改进其软件过程的活动。

 

CMM经过定义能力成熟度的5个等级，引导软件开发机构不断识别出其软件过程的缺陷，并指出应该作哪些改进，可是，它并不提供作这些改进的具体措施。
能力成熟度的5个等级从低到高依次是：  初始级（又称为1级），可重复级（又称为2级），已定义级（又称为3级），已管理级（又称为4级）和优化级（又称为5级）。下面介绍这5个级别的特色。

 

1. 初始级

 

软件过程的特征是无序的，有时甚至是混乱的。几乎没有什么过程是通过定义的（即没有一个定型的过程模型），项目可否成功彻底取决于开发人员的我的能力。

处于这个最低成熟度等级的软件机构，基本上没有健全的软件工程管理制度，其软件过程彻底取决于项目组的人员配备，因此具备不可预测性，人员变了过程也随之改变。若是一个项目碰巧由一个杰出的管理者和一支有经验、有能力的开发队伍承担，则这个项目多是成功的。可是，更常见的状况是，因为缺少健全的管理和周密的计划，延期交付和费用超支的状况常常发生，结果，大多数行动只是应付危机，而不是完成事先计划好的任务。
总之，处于1级成熟度的软件机构，其过程能力是不可预测的，其软件过程是不稳定的，产品质量只能根据相关人员的我的工做能力而不是软件机构的过程能力来预测。

 

2. 可重复级

软件机构创建了基本的项目管理过程(过程模型),可跟踪成本、进度、功能和质量。已经创建起必要的过程规范，对新项目的策划和管理过程是基于之前相似项目的实践经验，使得有相似应用经验的软件项目可以再次取得成功。达到2级的一个目标是使项目管理过程稳定，从而使得软件机构能重复之前在成功项目中所进行过的软件项目工程实践。

处于2级成熟度的软件机构，针对所承担的软件项目已创建了基本的软件管理控制制度。经过对之前项目的观察和分析，能够提出针对现行项目的约束条件。项目负责人跟踪软件产品开发的成本和进度以及产品的功能和质量，而且识别出为知足约束条件所应解决的问题。已经作到软件需求条理化，并且其完整性是受控制的。已经制定了项目标准，而且软件机构能确保严格执行这些标准。项目组与客户及承包商已经创建起一个稳定的、可管理的工做环境。

处于2级成熟度的软件机构的过程能力能够归纳为，软件项目的策划和跟踪是稳定的，已经为一个有纪律的管理过程提供了可重复之前成功实践的项目环境。软件项目工程活动处于项目管理体系的有效控制之下，执行着基于之前项目的准则且合乎现实的计划。

3. 已定义级

软件机构已经定义了完整的软件过程（过程模型），软件过程已经文档化和标准化。全部项目组都使用文档化的、通过批准的过程来开发和维护软件。这一级包含了第2级的所有特征。
在第3级成熟度的软件机构中，有一个固定的过程小组从事软件过程工程活动。当须要时，过程小组能够利用过程模型进行过程例化活动，从而得到一个针对某个特定的软件项目的过程实例，并投入过程运做而开展有效的软件项目工程实践。同时，过程小组还能够推动软件机构的过程改进活动。在该软件机构内实施了培训计划，可以保证全体项目负责人和项目开发人员具备完成承担的任务所要求的知识和技能。

处于3级成熟度的软件机构的过程能力能够归纳为，不管是管理活动仍是工程活动都是稳定的。软件开发的成本和进度以及产品的功能和质量都受到控制，并且软件产品的质量具备可追溯性。这种能力是基于在软件机构中对已定义的过程模型的活动、人员和职责都有共同的理解。

 

4. 已管理级

软件机构对软件过程（过程模型和过程实例）和软件产品都创建了定量的质量目标，全部项目的重要的过程活动都是可度量的。该软件机构收集了过程度量和产品度量的方法并加以运用，能够定量地了解和控制软件过程和软件产品，并为评定项目的过程质量和产品质量奠基了基础。这一级包含了第3级的所有特征。

处于4级成熟度的软件机构的过程能力能够归纳为，软件过程是可度量的，软件过程在可度量的范围内运行。这一级的过程能力容许软件机构在定量的范围内预测过程和产品质量趋势，在发生偏离时能够及时采起措施予以纠正，而且能够预期软件产品是高质量的。

 

 5. 优化级

软件机构集中精力持续不断地改进软件过程。这一级的软件机构是一个以防止出现缺陷为目标的机构，它有能力识别软件过程要素的薄弱环节，并有足够的手段改进它们。在这样的机构中，能够得到关于软件过程有效性的统计数据，利用这些数据能够对新技术进行成本/效益分析，并能够优化出在软件工程实践中可以采用的最佳新技术。这一级包含了第4级的所有特征。

这一级的软件机构能够经过对过程实例性能的分析和肯定产生某一缺陷的缘由，来防止再次出现这种类型的缺陷；经过对任何一个过程实例的分析所得到的经验教训均可以成为该软件机构优化其过程模型的有效依据，从而使其余项目的过程实例获得优化。这样的软件机构能够经过从过程实施中得到的定量的反馈信息，在采用新思想和新技术的同时测试它们，以不断地改进和优化软件过程。

处于5级成熟度的软件机构的过程能力能够归纳为，软件过程是可优化的。这一级的软件机构可以持续不断地改进其过程能力，既对现行的过程实例不断地改进和优化，又借助于所采用的新技术和新方法来实现将来的过程改进。
一些统计数字代表，提升一个完整的成熟度等级大约须要花18个月到3年的时间，可是从第1级上升到第2级有时要花3年甚至5年时间。这说明要向一个迄今仍处于混乱的和被动的行动方式的软件机构灌输系统化的方式，将多么困难。

 

13.8  小结

 

软件工程包括技术和管理两方面的内容，是技术与管理紧密结合的产物。只有在科学而严格的管理之下，先进的技术方法和优秀的软件工具才能真正发挥出威力。所以，有效的管理是大型软件工程项目成功的关键。
软件项目管理始于项目计划，而第一项计划活动就是估算。为了估算项目工做量和完成期限，首先须要预测软件规模。

度量软件规模的经常使用技术主要有代码行技术和功能点技术。这两种技术各有优缺点，应该根据项目特色及从事计划工做的人对这两种技术的熟悉程度，选用适用的技术。

根据软件规模能够估算出完成该项目所需的工做量，经常使用的估算模型为静态单变量模型、动态多变量模型和COCOMO2模型。为了使估算结果更接近实际值，一般至少同时使用上述3种模型中的两种。经过比较和协调使用不一样模型得出的估算值，有可能获得比较准确的估算结果。成本估算模型一般也同时提供了估算软件开发时间的方程式，这样估算出的开发时间是正常开发时间，经验代表，用增长开发人员的方法最多能够把开发时间减小到正常开发时间的75%。

 

管理者必须制定出一个足够详细的进度表，以便监督项目进度并控制整个项目。经常使用的制定进度计划的工具备Gantt图和工程网络，这两种工具各有优缺点，一般，联合使用Gantt图和工程网络来制定进度计划并监督项目进展情况。
高素质的开发人员和合理的项目组组织结构，是软件项目取得成功的关键。比较典型的组织结构有民主制程序员组、主程序员组和现代程序员组等3种，这3种组织方式的适用场合并不相同。

 

软件质量保证是在软件过程当中的每一步都进行的活动。软件质量保证措施主要有基于非执行的测试（也称为复审）、基于执行的测试（即一般所说的测试）和程序正确性证实。软件复审是最重要的软件质量保证活动之一，它的优势是在改正错误的成本相对比较低时就能及时发现并排除软件错误。
软件配置管理是应用于整个软件过程当中的保护性活动，是在软件整个生命期内管理变化的一组活动。软件配置管理的目标是，使变化可以更正确且更容易被适应，在须要修改软件时减小为此而花费的工做量。

能力成熟度模型（CMM）是改进软件过程的有效策略。它的基本思想是，由于问题是管理软件过程的方法不恰当形成的，因此采用新技术并不会自动提升软件生产率和软件质量，应该下大力气改进对软件过程的管理。事实上对软件过程的改进不可能一蹴而就，所以，CMM以增量方式逐步引入变化，它明确地定义了5个成熟度等级，一个软件开发组织能够用一系列小的改良性步骤迈入更高的成熟度等级。