第13章---软件项目管理.ppt

1、第十章 软件项目管理,10.1 估算软件规模10.2 工作量估算10.3 进度计划10.4 人员组织10.5 软件配置管理10.6 能力成熟度模型CMM,第10章 软件项目管理,项目管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到项目既定目标的过程。软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。软件项目管理过程源于项目计划，主要活动是“估算”。软件计划详尽地描述了软件过程，包括采用的生命周期模型、开发组织结构、责任分配、管理目标和优先级、所用技术和CASE工具，以及详细的进度、预算和资源分配。整个计划的基础是工作量估算和完成期限估算。PSP训

2、练,软件度量技术,代码行技术:是一种比较简单的定量估算软件规模的方法。根据以往开发类似产品的经验和历史数据，估计实现一个功能需要的源程序行数。把实现每个功能需要的源程序行数累加起来，就得到实现整个软件需要的源程序行数。,用代码行技术度量软件规模时，当程序较小时常用的单位是代码行数(LOC)，当程序较大时常用的单位是千行代码数(KLOC)。,为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别作出估计。每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出这三种规模的平均值a，b，和m 之后，再用下式计算程序规模的估计值：,-PERT技术,优点:主要是

3、代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。缺点是：源程序仅是软件配置的一个成分，用不同语言实现同一个软件所需要的代码行数并不相同；用它的规模代表整个软件的规模似乎不太合理；这种方法不适用于非过程语言。为了克服代码行技术的缺点，人们又提出了功能点技术。,用功能点（FP）为单位度量软件规模1. 信息域特性功能点技术定义了信息域的5个特性，分别是输入项数(Inp)、输出项数(Out)、查询数(Inq)、主文件数(Maf)和外部接口数(Inf)。,功能点技术：依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。,（1）输入项数：用户向软件输入的项数，这些输入给软件提供面向应用

4、的数据。输入不同于查询，后者单独计数，不计入输入项数中。（2）输出项数：软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和出错信息等。报表内的数据项不单独计数。（3）查询数： 查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。（4）主文件数：逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。（5）外部接口数：机器可读的全部接口（例如磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。,2. 估算功能点的步骤估算出一个软件的功能点数（即软件规模）：（1） 计算未调整的功能点数CT 把产品信息域的每个特性(即Inp、O

5、ut、Inq、Maf和Inf)都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数（例如，一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，而一个复杂级的输入项分配6个功能点）。 未调整的功能点数UFP： CT=a1Inp+a2Out+a3Inq+a4Maf+a5Inf其中，ai(1i5)是信息域特性系数，其值由相应特性的复杂级别决定。,(2) 计算技术复杂性因子TCF这一步骤度量14种技术因素对软件规模的影响程度。这些因素包括高处理率、性能标准（例如，响应时间）、联机更新等，用Fi(1i14)代表这些因素。根据软件的特点，为每个因素分配一个从0（不存在或对

6、软件规模无影响）到5（有很大影响）的值。技术因素对软件规模的综合影响程度DI： DI=技术复杂性因子TCF由下式计算： TCF=0.65+0.01DI因为DI的值在070之间，所以TCF的值在0.651.35之间。,（3） 计算功能点数FP FP=CTTCF功能点数与所用的编程语言无关，看起来功能点技术比代码行技术更合理一些。但是，在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。,软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月（pm)。由于支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结

7、出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境。,10.2 工作量估算,这类模型的总体结构形式如下： E=A+B(ev)C其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量（KLOC或FP）。下面给出几个典型的静态单变量模型。面向KLOC的估算模型(1) Walston_Felix模型 E=5.2(KLOC)0.91(2) Bailey_Basili模型 E=5.5+0.73(KLOC)1.16,10.2.1 静态单变量模型,可以看出，对于相同的KLOC或FP值，用不同模型估算将得出不同的结果。主要原因是，这些模型多数都是仅根据若干应用领域中有限

8、个项目的经验数据推导出来的，适用范围有限。 因此，必须根据当前项目的特点选择适用的估算模型，并且根据需要适当地调整（例如，修改模型常数）估算模型。,1981年Boehm在软件工程经济学中首次提出了COCOMO模型， COCOMO是构造性成本模型（Constructive Cost Model)的英文缩写。 1997年Boehm等人提出的COCOMO2模型，是原COCOMO模型的修订版，它反映了十多年来在成本估计方面所积累的经验。 COCOMO2给出了3个层次的软件开发工作量估算模型，这3个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。,10.2.2 COCOMO2模型,这3个层次

9、的估算模型分别是： （1） 应用系统组成模型。这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。（2） 早期设计模型。这个模型适用于体系结构设计阶段。（3） 后体系结构模型。这个模型适用于完成体系结构设计之后的软件开发阶段。,下面以后体系结构模型为例，介绍COCOMO2模型。该模型把软件开发工作量表示成代码行数（KLOC）的非线性函数： E=(3)其中， E是开发工作量（以人月为单位）， a是模型系数， KLOC是估计的源代码行数， b是模型指数， fi(i=117)是成本因素。,每个成本因素都根据它的重要程度和对工作量影响大小被赋予一定数值（称为工作量系数）。

10、Boehm把成本因素划分成产品因素、平台因素、人员因素和项目因素等4类。 与原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述变化:（1） 新增加了4个成本因素，它们分别是要求的可重用性、需要的文档量、人员连续性（即人员稳定程度）和多地点开发。这个变化表明，这些因素对开发成本的影响日益增加。（2） 略去了原始模型中的2个成本因素（计算机切换时间和使用现代程序设计实践）。,（3） 某些成本因素（分析员能力、平台经验、语言和工具经验）对生产率的影响（即工作量系数最大值与最小值的比率）增加了，另一些成本因素（程序员能力）的影响减小了。 为了确定工作量方程中模型指数b的值，原始的COC

11、OMO模型把软件开发项目划分成组织式、半独立式和嵌入式这样3种类型，并指定每种项目类型所对应的b值（分别是1.05，1.12和1.20）。COCOMO2采用了更加精细得多的b分级模型，这个模型使用5个分级因素Wi(1i5),其中每个因素都划分成从甚低（Wi=5)到特高（Wi=0)的6个级别，然后用下式计算b的数值：,b=(4)因此，b的取值范围为1.011.26。显然，这种分级模式比原始COCOMO模型的分级模式更精细、更灵活。COCOMO2使用的5个分级因素如下所述： （1） 项目先例性。这个分级因素指出，对于开发组织来说该项目的新奇程度。诸如开发类似系统的经验，需要创新体系结构和算法，以及

12、需要并行开发硬件和软件等因素的影响，都体现在这个分级因素中。,（2） 开发灵活性。这个分级因素反映出，为了实现预先确定的外部接口需求及为了及早开发出产品而需要增加的工作量。（3） 风险排除度。这个分级因素反映了重大风险已被消除的比例。在多数情况下，这个比例和指定了重要模块接口（即选定了体系结构）的比例密切相关。（4） 项目组凝聚力。这个分级因素表明了开发人员相互协作时可能存在的困难。这个因素反映了开发人员在目标和文化背景等方面相一致的程度，以及开发人员组成一个小组工作的经验。,（5） 过程成熟度。这个分级因素反映了按照能力成熟度模型度量出的项目组织的过程成熟度。 在原始的COCOMO模型中，仅

13、粗略地考虑了前两个分级因素对指数b之值的影响。 工作量方程中模型系数a的典型值为3.0，在实际工作中应该根据历史经验数据确定一个适合本组织当前开发的项目类型的数值。,不论从事哪种技术性项目，实际情况都是，在实现一个大目标之前往往要把它分解成一系列的比较容易管理的子项目（也称为作业）。这些任务中有一些是处于“关键路径”之外的，其完成时间如果没有严重拖后，就不会影响整个项目的完成时间；其他任务则处于关键路径之中，如果这些“关键任务”的进度拖后，则整个项目的完成日期就会拖后，管理人员应该高度关注关键任务的进展情况。 项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能

14、及时发现拖延进度的情况。为达到上述目标，管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。,10.3 进度计划,Gantt（甘特）图是历史悠久、应用广泛的制定进度计划的工具，下面通过一个非常简单的例子介绍这种工具。 假设有一座陈旧的矩形木板房需要重新油漆。这项工作必须分3步完成： 首先刮掉旧漆，然后刷上新漆，最后清除溅在窗户上的油漆。假设一共分配了15名工人去完成这项工作，然而工具却很有限： 只有5把刮旧漆用的刮板，5把刷漆用的刷子，5把清除溅在窗户上的油漆用的小刮刀。怎样安排才能使工作进行得更有效呢?,10.3.1 Gantt图,一种做法是首先刮掉四面墙壁上的旧漆，然后给每

15、面墙壁都刷上新漆，最后清除溅在每个窗户上的油漆。显然这是效率最低的做法，因为总共有15名工人，然而每种工具却只有5件，这样安排工作在任何时候都有10名工人闲着没活干。,读者可能已经想到，应该采用“流水作业法”，也就是说，首先由5名工人用刮板刮掉第1面墙上的旧漆(这时其余10名工人休息)，当第1面墙刮净后，另外5名工人立即用刷子给这面墙刷新漆(与此同时拿刮板的5名工人转去刮第2面墙上的旧漆)，一旦刮旧漆的工人转到第3面墙而且刷新漆的工人转到第2面墙以后，余下的5名工人立即拿起刮刀去清除溅在第1面墙窗户上的油漆，。这样安排每个工人都有活干，因此能够在较短的时间内完成任务。假设木板房的第2、4两面墙

16、的长度比第1、3两面墙的长度长一倍，此外，不同工作需要用的时间长短也不同，刷新漆最费时间，其次是刮旧漆，清理(即清除溅在窗户上的油漆)需要的时间最少。,可以使用图1中的Gantt图描绘上述流水作业过程： 在时间为零时开始刮第1面墙上的旧漆，两小时后刮旧漆的工人转去刮第2面墙，同时另5名工人开始给第1面墙刷新漆，每当给一面墙刷完新漆之后，第3组的5名工人立即清除溅在这面墙窗户上的漆。从图1可以看出12小时后刮完所有旧漆，20小时后完成所有墙壁的刷漆工作，再过2小时后清理工作结束。因此全部工程在22小时后结束，如果用前述的第一种做法，则需要36小时。,图9.1 旧木板房刷漆工程的Gantt图,刮第

17、1面墙,柒第1面墙,刮第3面墙,柒第3面墙,刮第2面墙,刮第4面墙,柒第2面墙,柒第4面墙,Gantt图能很形象地描绘任务分解情况，以及每个子任务(作业)的开始时间和结束时间，因此,它是进度计划和进度管理的有力工具。它具有直观简明和容易掌握、容易绘制的优点，但是Gantt图也有3个主要缺点： (1) 不能显式地描绘各项作业彼此间的依赖关系；(2) 进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象；(3) 计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。,10.3.3 工程网络,当把一个工程项目分解成许多子任务，它们彼此间的依赖关系又比较复杂时，仅仅用Gantt图作为安

18、排进度的工具是不够的，不仅难于做出既节省资源又保证进度的计划，而且还容易发生差错。 工程网络是制定进度计划时另一种常用的图形工具，它同样能描绘任务分解情况以及每项作业的开始时间和结束时间，此外，它还显式地描绘各个作业彼此间的依赖关系。因此，工程网络是系统分析和系统设计的强有力的工具。,图9.2 旧木板房刷漆工程的工程网络,画出类似图2那样的工程网络之后，系统分析员就可以借助它的帮助估算工程进度了。为此需要在工程网络上增加一些必要的信息。首先，把每个作业估计需要使用的时间写在表示该项作业的箭头上方。注意，箭头长度和它代表的作业持续时间没有关系，箭头仅表示依赖关系，它上方的数字才表示作业的持续时间

19、。,10.3.4 估算工程进度,其次，为每个事件计算下述两个统计数字： 最早时刻EET和最迟时刻LET。这两个数字将分别写在表示事件的圆圈的右上角和右下角，如图3左下角的符号所示。事件的最早时刻是该事件可以发生的最早时间。通常工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。计算最早时刻EET使用下述3条简单规则：,图13.3 旧木板房刷漆工程的完整的工程网络,(1) 考虑进入该事件的所有作业；(2) 对于每个作业都计算它的持续时间与起始事件的EET之和；(3) 选取上述和数中的最大值作为该事件的最早时刻EET 按照这种方法，不难沿着工程网络从左

20、至右顺序算出每个事件的最早时刻，计算结果标在图3的工程网络中(每个圆圈内右上角的数字)。,事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻。 按惯例，最后一个事件(工程结束)的最迟时刻就是它的最早时刻。其他事件的最迟时刻在工程网络上从右至左按逆作业流的方向计算。计算最迟时刻LET使用下述3条规则： (1) 考虑离开该事件的所有作业；(2) 从每个作业的结束事件的最迟时刻中减去该作业的持续时间；(3) 选取上述差数中的最小值作为该事件的最迟时刻LET。,图10.3中有几个事件的最早时刻和最迟时刻相同，这些事件即为关键路径，在图中关键路径用粗线箭头表示。关键路径上的事件(关键

21、事件)必须准时发生，组成关键路径的作业(关键作业)的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。 工程项目的管理人员应该密切注视关键作业的进展情况，如果关键事件出现的时间比预计的时间晚，则会使最终完成项目的时间拖后；如果希望缩短工期，只有往关键作业中增加资源才会有效果。,10.3.5 关键路径,不在关键路径上的作业有一定程度的机动余地实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些，而并不影响工程的结束时间。 一个作业可以有的全部机动时间等于它的结束事件的最迟时刻减去它的开始事件的最早时刻，再减去这个作业的持续时间： 机动时间=(LET)结束-持续时

22、间-(EET)开始,10.3.6 机动时间,图13.4 旧木板房刷漆工程改进的Gantt图之一,工程网络比Gantt图优越的地方： 它显式地定义事件及作业之间的依赖关系，Gantt图只能隐含地表示这种关系。但是Gantt图的形式比工程网络更简单更直观，为更多的人所熟悉，因此，应该同时使用这两种工具制订和管理进度计划，使它们互相补充取长补短。 总之, 工作量估计技术可以帮助我们估计每项任务的工作量，根据人力分配情况，可以进一步确定每项任务的持续时间。从这些基本数据出发，根据作业之间的依赖关系，利用工程网络和Gantt图可以制定出合理的进度计划，并且能够科学地管理软件开发工程的进展情况。,软件项目

23、成功的关键是有高素质的软件开发人员。然而大多数软件的规模都很大，单个软件开发人员无法在给定期限内完成开发工作，因此，必须把多名软件开发人员合理地组织起来，使他们有效地分工协作共同完成开发工作。 经验表明，项目组组织得越好，其生产率越高，而且产品质量也越好。 除了追求更好的组织方式之外，每个管理者的目标都是建立有凝聚力的项目组。一个有高度凝聚力的小组，由一批团结得非常紧密的人组成，他们的整体力量大于个体力量的总和。一旦项目组具有了凝聚力，成功的可能性就大大增加了。,10.4 人员组织,其特点是，小组成员完全平等，享有充分民主，通过协商做出技术决策。因此，小组成员之间的通信是平行的，如果小组内有n

24、个成员，则可能的通信信道共有n(n-1)/2条。 程序设计小组的人数不能太多,否则组员间彼此通信的时间将多于程序设计时间。此外,通常不能把一个软件系统划分成大量独立的单元,因此,如果程序设计小组人数太多,则每个组员所负责开发的程序单元与系统其他部分的界面将是复杂的,不仅出现接口错误的可能性增加,而且软件测试将既困难又费时间。,10.4.1 民主制程序员组,优点:组员们对发现程序错误持积极的态度，这种态度有助于更快速地发现错误，从而导致高质量的代码。组员们享有充分民主，小组有高度凝聚力，组内学术空气浓厚，有利于攻克技术难关。因此，当有难题需要解决时，也就是说，当所要开发的软件的技术难度较高时，采

25、用民主制程序员组是适宜的。缺点： 由于没有明确的权威指导开发工程的进行,组员间将缺乏必要的协调,最终可能导致工程失败。 为了使少数经验丰富、技术高超的程序员在软件开发过程中能够发挥更大作用，程序设计小组也可以采用下一小节中介绍的另外一种组织形式。,美国IBM公司在20世纪70年代初期开始采用主程序员组的组织方式。采用这种组织方式主要出于下述几点考虑： (1) 软件开发人员多数比较缺乏经验；(2) 程序设计过程中有许多事务性的工作，例如大量信息的存储和更新；(3) 多渠道通信很费时间，将降低程序员的生产率。,10.4.2 主程序员组,主程序员组用经验多、技术好、能力强的程序员作为主程序员，同时，

26、利用人和计算机在事务性工作方面给主程序员提供充分支持，而且所有通信都通过一两个人进行。 这种组织方式类似于外科手术小组组织： 主刀大夫对手术全面负责，并且完成制订手术方案、开刀等关键工作，同时又有麻醉师、护士长等技术熟练的专门人员协助和配合他的工作。此外，必要时手术组还要请其他领域的专家（例如，心脏科医生或妇产科医生）协助。,主程序员组的两个重要特性： （1） 专业化，该组每名成员仅完成他们受过专业训练的那些工作。（2） 层次性，主刀大夫指挥每名组员工作，并对手术全面负责。 典型的主程序员组的组织形式如图9.5所示。该组由主程序员、后备程序员、编程秘书以及13名程序员组成。在必要的时候，该组还

27、有其他领域的专家协助。,图11.1 主程序员组的结构,主程序员组核心人员的分工如下所述： （1） 主程序员既是成功的管理人员又是经验丰富、技术好、能力强的高级程序员，负责体系结构设计和关键部分（或复杂部分）的详细设计，并且负责指导其他程序员完成详细设计和编码工作。所有接口问题都由主程序员处理。主程序员对每行代码的质量负责，因此，他还要对组内其他成员的工作成果进行复查。,（2） 后备程序员也应该技术熟练而且富于经验，他协助主程序员工作并且在必要时（例如，主程序员生病、出差或“跳槽”）接替主程序员的工作。因此，后备程序员必须在各方面都和主程序员一样优秀，并且对本项目的了解也应该和主程序员一样深入。

28、平时，后备程序员的工作主要是，设计测试方案、分析测试结果及独立于设计过程的其他工作。（3） 编程秘书负责完成与项目有关的全部事务性工作，例如，维护项目资料库和项目文档，编译、链接、执行源程序和测试用例。,主程序员应该是高级程序员和优秀管理者的结合体, 承担主程序员工作需要同时具备这两方面的才能。其次后备程序员更难找。人们期望后备程序员像主程序员一样优秀，但是，他们必须坐在“替补席”上，拿着较低的工资等待随时接替主程序员的工作。几乎没有一个高级程序员或高级管理人员愿意接受这样的工作。第三，编程秘书也很难找到。专业的软件技术人员一般都厌烦日常的事务性工作，但是，人们却期望编程秘书整天只干这类工作。

29、 我们需要一种更合理、更现实的组织程序员组的方法，这种方法应该能充分结合民主制程序员组和主程序员组的优点，并且能用于实现更大规模的软件产品。,优点：小组成员都对发现程序错误持积极、主动的态度。但是，使用主程序员组的组织方式时，主程序员对每行代码的质量负责，因此，他必须参与所有代码审查工作。由于主程序员同时又是负责对小组成员进行评价的管理员，他参与代码审查工作就会把所发现的程序错误与小组成员的工作业绩联系起来，从而造成小组成员出现不愿意发现错误的心理。,10.4.3 现代程序员组,解决方法:取消主程序员的大部分行政管理工作。前面已经指出，很难找到既是高度熟练的程序员又是成功的管理员的人，取消主程

30、序员的行政管理工作，不仅解决了小组成员不愿意发现程序错误的心理问题，也使得寻找主程序员的人选不再那么困难。于是，实际的“主程序员”应该由两个人共同担任： 一个技术负责人，负责小组的技术活动；一个行政负责人，负责所有非技术性事务的管理决策。这样的组织结构如图9.6所示。技术组长自然要参与全部代码审查工作，因为他要对代码的各方面质量负责；相反，行政组长不可以参与代码审查工作，因为他的职责是对程序员的业绩进行评价。行政组长应该在常规调度会议上了解每名组员的技术能力和工作业绩。,图11.2 现代程序员组的结构,在开始工作之前明确划分技术组长和行政组长的管理权限是很重要的。但是，即使已经做了明确分工，有

31、时也会出现职责不清的矛盾。例如，考虑年度休假问题，行政组长有权批准某个程序员休年假的申请，因为这是一个非技术性问题，但是技术组长可能马上否决了这个申请，因为已经接近预定的项目结束日期，目前人手非常紧张。 解决这类问题的办法是求助于更高层的管理人员w为行政组长和技术组长都认为是属于自己职责范围内的事务，制定一个处理方案。,图11.3 大型项目的技术管理组织结构,程序员组成员人数不宜过多，当软件项目规模较大时，应该把程序员分成若干个小组，采用图11.3所示的组织结构,描绘的是技术管理组织的结构，非技术管理组织的结构与此类似。在项目经理的指导下进行的，程序员向他们的组长汇报工作，而组长向项目经理汇报

32、工作。,把民主制程序员组和主程序员组的优点结合起来的另一种方法，是在合适的地方采用分散做决定的方法。这样做有利于形成畅通的通信渠道，以便充分发挥每个程序员的积极性和主动性，集思广益攻克技术难关。这种组织方式对于适合采用民主方法的那类问题（例如，研究性项目或遇到技术难题需要用集体智慧攻关）非常有效。尽管这种组织方式适当地发扬了民主，但是上下级之间的箭头（即管理关系）仍然是向下的，也就是说，是在集中指导下发扬民主。显然，如果程序员可以指挥项目经理，则只会引起混乱。,图13.4 包含分散决策的组织方式,任何软件开发都是迭代过程，也就是说，在设计过程会发现需求说明书中的问题，在实现过程又会暴露出设计中

33、的错误，。此外，随着时间推移客户的需求也会或多或少发生变化。因此，在开发软件的过程中，变化（或称为变动）既是必要的，又是不可避免的。但是，变化也很容易失去控制，如果不能适当地控制和管理变化，势必造成混乱并产生许多严重的错误。,10.5 软件配置管理,软件配置管理是在软件的整个生命期内管理变化的一组活动。具体地说，这组活动用来： 标识变化； 控制变化； 确保适当地实现了变化； 向需要知道这类信息的人报告变化。 软件配置管理不同于软件维护。维护是在软件交付给用户使用后才发生的，而配置管理是在软件项目启动时就开始，一直持续到软件退役后才终止的一组跟踪和控制活动。 软件配置管理的目标是，使变化更正确且

34、更容易被适应，在必须变化时减少所需花费的工作量。,1. 软件配置项软件过程的输出信息可以分为3类： 计算机程序（源代码和可执行程序）； 描述计算机程序的文档 （供技术人员或用户使用）； 数据（程序内包含的或在程序外的）。 这些项组成了在软件过程中产生的全部信息，我们把它们统称为软件配置，而这些项就是软件配置项。,10.5.1 软件配置,为了开发出高质量的软件产品，软件开发人员不仅要努力保证每个软件配置项正确，而且必须保证一个软件的所有配置项是完全一致的。 可以把软件配置管理看作是应用于整个软件过程的软件质量保证活动，是专门用于管理变化的软件质量保证活动。,2. 基线 基线是一个软件配置管理概念

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

36、具，为防止不同版本的工具产生的结果不同，应该把软件工具也基线化，并且列入到综合的配置管理过程之中。,软件配置管理是软件质量保证的重要一环，它的主要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告。具体来说，软件配置管理主要有5项任务： 标识 版本控制 变化控制 配置审计 报告,10.5.2 软件配置管理过程,1. 标识软件配置中的对象可以标识出两类对象： 基本对象和聚集对象（可以把聚集对象作为代表软件配置完整版本的一种机制）。基本对象是软件工程师在分析、设计、编码或测试过程中创建出来的“文本单元”，例如，需求规格说明的一个段落、一个模

37、块的源程序清单或一组测试用例。聚集对象是基本对象和其他聚集对象的集合。对象名是无二义性地标识该对象的一个字符串。所设计的标识模式必须能无歧义地标识每个对象的不同版本。,2. 版本控制版本控制联合使用规程和工具，以管理在软件工程过程中所创建的配置对象的不同版本。借助于版本控制技术，用户能够通过选择适当的版本来指定软件系统的配置。实现方法：把属性和软件的每个版本关联起来，然后通过描述一组所期望的属性来指定和构造所需要的配置。这些“属性”，既可以简单到仅是赋给每个配置对象的具体版本号，也可以复杂到是一个布尔变量串，其指明施加到系统上的功能变化的具体类型。,3. 变化控制对于大型软件开发项目来说，无控

38、制的变化将迅速导致混乱。变化控制把人的规程和自动工具结合起来，以提供一个控制变化的机制。典型的变化控制过程如下： 接到变化请求之后，首先评估该变化在技术方面的得失、可能产生的副作用、对其他配置对象和系统功能的整体影响以及估算出的修改成本。评估的结果形成“变化报告”，该报告供“变化控制审批者”审阅。变化控制审批者既可以是一个人也可以由一组人组成。,为每个被批准的变化都生成一个“工程变化命令”，其描述将要实现的变化，必须遵守的约束以及复审和审计的标准。把要修改的对象从项目数据库中“提取（check out）”出来，进行修改并应用适当的SQA活动。最后，把修改后的对象“提交（check in）”进数

39、据库，并用适当的版本控制机制创建该软件的下一个版本。 “提交”和“提取”过程实现了变化控制的两个主要功能访问控制和同步控制。访问控制决定哪个软件工程师有权访问和修改一个特定的配置对象，同步控制有助于保证由两名不同的软件工程师完成的并行修改不会相互覆盖。,在一个软件配置项变成基线之前，仅需应用非正式的变化控制，该配置对象的开发者可以对它进行任何合理的修改。一旦该对象经过了正式技术复审并获得批准，就创建了一个基线，而一旦一个软件配置项变成了基线，就开始实施项目级的变化控制。这时，为了进行修改开发者必须获得项目管理者的批准（如果变化是“局部的”），如果变化影响到其他软件配置项，还必须得到变化控制审批

40、者的批准。每个变化必须再次评估，并且要跟踪和复审所有变化。,4. 配置审计为了确保实现所需要的变化，通常从下述两方面采取措施： 正式的技术复审； 软件配置审计。正式的技术复审关注被修改后的配置对象的技术正确性。复审者审查该对象以确定它与其他软件配置项的一致性，并检查是否有遗漏或副作用。软件配置审计通过评估配置对象的那些通常不在复审过程中考虑的特征（例如，修改时是否遵循了软件工程标准，是否在该配置项中显著地标明了所做的修改，是否注明了修改日期和修改者，是否适当地更新了所有相关的软件配置项，是否遵循了标注变化、记录变化和报告变化的规程），而成为对正式技术复审的补充。,5. 状态报告配置状态报告它回

41、答下述问题： 发生了什么事？ 谁做的这件事？ 这件事是什么时候发生的？ 它将影响哪些其他事物？ 配置状态变化对大型软件开发项目的成功有重大影响。如两名开发人员可能试图按照相互冲突的想法去修改同一个软件配置项；软件工程队伍可能耗费几个人月的工作量根据过时的硬件规格说明开发软件；察觉到所建议的修改有严重副作用的人可能还不知道该项修改正在进行。配置状态报告通过改善所有相关人员之间的通信，帮助消除这些问题。,10.6 国际标准-能力成熟度模型,ISO9000质量标准强调质量并不是在产品检验中得到的，而是在生产的全过程中形成的。ISO9000-3的全称是“质量管理和质量保证标准第三部分：在软件开发、供应

42、和维护中的使用指南”。ISO9000-3要求软件开发机构建立质量管理体系ISO9000-3阐述了供方和需方应该怎样进行有组织的质量管理活动，才能得到较为满意的软件产品；规定了从双方签订开发合同到设计、实现和维护的整个软件生命周期中应该实施的质量管理活动，但是，并没有规定具体的质量管理和质量检验的方法和步骤。,13.6 国际标准-能力成熟度模型,ISO/IEC 12207软件生命周期过程标准指导软件过程实施的一个标准，从多个角度阐述了软件生命周期各个过程中的活动，对规范软件开发过程，协调各类人员之间的关系，都具有指导作用。建立了一个最高层次的软件生命周期体系结构生命周期从一个设想或需求开始，直至

43、软件被废弃(退役)时终止。体系结构由一组相互关联的过程集组成，所有过程都遵守了两条基本原则：模块化和责任。标准中的过程被分成三大类：主要过程，支持过程和组织过程。主要过程是生命周期中的原动力，它们是：获取、供应、开发、运行和维护。ISO/IEC 12207是从过程实施的角度对软件生命周期过程进行规范的标准,10.6 国际标准-能力成熟度模型,ISO/IEC TR 15504软件过程评估标准是从过程评估的角度对软件过程进行规范的标准。为软件过程评估提供了一个框架，并为实施评估以确保各种级别的一致性和可重复性提出了一个最小需求。具有两维结构：一个是过程维（客户供应者、工程过程、支持过程、管理过程、

44、组织过程），另一个是能力维（第0级不完全级、可实施级、有管理级、可创建级、可预测级、优化级）。融合进了能力成熟度模型(CMM)类似的能力等级。用户可以通过不断提高能力等级的方法，提高自己的软件过程能力。,10.6 国际标准-能力成熟度模型,能力成熟度模型软件质量问题是由我们管理软件过程的方法不当引起的。新软件技术的运用并不会自动提高生产率和软件质量。有助于软件开发组织建立一个有规律的、成熟的软件过程。软件过程既包括了软件生产的技术方面又包括了管理方面。CMM策略力图改进软件过程的管理，而在技术方面的改进是其必然的结果。对软件过程的改进不可能在一夜之间完成，CMM是以增量方式逐步引入变化的。CM

45、M明确地定义了5个不同的成熟度等级，一个软件开发组织可用一系列小的改良性步骤向更高的成熟度等级迈进。,10.6 国际标准-能力成熟度模型,能力成熟度模型的结构成熟度等级(Maturity Levels)：五个成熟度等级构成了CMM的顶层结构。过程能力(Process Capability)：软件过程能力描述，通过遵循软件过程能实现预期结果的程度。关键过程域(Key Process Areas,KPA)：每个成熟度等级由若干关键过程域组成。每个关键过程域都标识出一串相关的活动，当把这些活动都完成时所达到的一组目标，对建立该过程成熟度等级是至关重要的。目标(Goals)：目标概括了关键过程域中的关

46、键实践，并可用于确定一个组织或项目是否已有效地实施了该关键过程域。目标表示每个关键过程域的范围、边界和意图。公共特性(Common Features)：能指示一个关键过程域的实施和规范化是否是有效的、可重复的和持久的属性。关键实践(Key Practices)：每个关键过程域都用若干关键实践描述，关键实践描述是对关键过程域的有效实施和规范化贡献最大的基础设施和活动。,图13.4 CMM结构,能力成熟度等级,1.初始级：软件过程的特征是无序的，有时甚至是混乱的。几乎没有什么过程是经过定义的，项目能否成功完全取决于个人能力。2.可重复级：建立了基本的项目管理过程，以追踪成本、进度和功能性。已建立必

47、要的过程规范，可以重复以前类似项目所取得的成功。3.定义级：用于管理工程活动的软件过程已经文档化和标准化，并且已经集成到整个组织的软件过程中。这一级包含了第2级的所有特征。4.管理级：已收集了软件过程和产品质量的详细度量数据，使用这些详细的度量数据，能够定量地理解和控制软件过程和产品。这一级包含了第3级的所有特征。5.优化级：通过定量的反馈能够实现持续的过程改进，这些反馈是从过程及对新想法和技术的测试中获得的。这一级包含了第4级的所有特征。,软件过程成熟度模型的关键子过程域,* 表示个体软件过程 PSP的关键子过程域。软件过程能力描述遵循一个软件过程所能达到的期望结果的范围。软件过程性能是指遵

48、循一个软件过程所能得到的实际结果。软件过程成熟度是指一个特定的过程被明确定义、管理、度量、控制以及有效的程度。,个体软件过程PSP,PSP是由美国CMU/SEI 的 Watts Humphrey 领导开发的。他对104位参与PSP培训的软件人员的统计数据表明(程序规模从50至5000行不等)，在应用PSP后：总的差错减少58.0%，在测试阶段发现的差错减少71.9%，生产效率提高20.8%。PSP的结果表明，软件缺陷绝大多数是由于对问题的错误理解或简单的失误所造成，只有很少一部分是由于复杂的逻辑关系所产生。PSP的结果还表明，在编程阶段的缺陷引入率是设计阶段的3.5倍。因此，保障软件产品质量的一个重要途径是提高设计质量。在软件设计阶段，PSP的着眼点在于软件缺陷的预防。具体的途径是强化设计结束准则，而不是设计方法的选择。,