1、软件工程管理,1. 估算软件规模2. 工作量估算3. 进度计划4. 人员组织5. 质量保证6. 软件配置管理7. 能力成熟度模型8. 小结,1,大型软件项目的失败并不是由于软件工程师的无能，其主要原因是管理不善。管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。,2,软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算。为了估算项目的工作量和完成期限，首先需要估算软件的规模。,3,1 估算软件规模 1.1 代码行技术,代码行技术是简单的定量估算软件规模的
2、方法。它依据开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。在有大量数据时，这种方法估计出的数值还是比较准确的。把实现每个功能所需要的源程序行数累加起来，就可得到实现整个软件所需要的源程序行数。,4,1.1 代码行技术,为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做出估计。分别估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，算出这3种规模的平均值之后，再用下式计算程序规模的估计值： L=(1)当程序较小时常用的单位是代码行数（LOC），当程序较大时常用的单位是千行代码数（KLOC）。,5,1.1 代码行技术,代码行技术的优点是，代码是
3、所有软件开发项目都有的“产品”，而且很容易计算代码行数。代码行技术的缺点是： 源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。,6,1.2 功能点技术(自学),功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP）为单位度量软件规模。1. 信息域特性功能点技术定义了信息域的5个特性输入项数(Inp)输出项数(Out)查询数(Inq)主文件数(Maf)外部接口数(Inf),7,1.2 功能点技术,（1） 输入项数：用户向软件输入的项数，这些输入给软件提供面向
4、应用的数据。输入不同于查询，后者单独计数，不计入输入项数中。（2） 输出项数：软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和出错信息等。报表内的数据项不单独计数。（3） 查询数：查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。（4） 主文件数：逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或一个独立的文件）的数目。（5） 外部接口数： 机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。,8,1.2 功能点技术,2. 估算功能点的步骤用下述3个步骤，可估算出一个软件的功能点数。Step1: 计算未调整的功能
5、点数UFPStep2: 计算技术复杂性因子TCFStep3: 计算功能点数FP,9,1.2 功能点技术,（1） 计算未调整的功能点数UFP把产品信息域的每个特性(即Inp、Out、Inq、Maf和Inf)都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数。例如，一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，而一个复杂级的输入项分配6个功能点。用下式计算未调整的功能点数UFP： UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf，其中，ai(1i5)是信息域特性系数，其值由相应特性的复杂级别决定，如下表所示。,10,1.2 功能点技术,1
6、1,1.2 功能点技术,(2) 计算技术复杂性因子TCF度量14种技术因素对软件规模的影响程度。这些因素包括高处理率、性能标准（例如，响应时间）、联机更新等，并用Fi(1i14)代表这些因素。根据软件的特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。然后，用下式计算技术因素对软件规模的综合影响程度DI： DI=,12,1.2 功能点技术,技术复杂性因子TCF由下式计算： TCF=0.65+0.01DI因为DI的值在070之间，所以TCF的值在0.651.35之间。（3） 计算功能点数FP用下式计算功能点数FP： FP=UFPTCF功能点数与所用的编程语言无关，似
7、乎更合理一些。但是，在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。,13,2 工作量估算,软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月（pm)。没有一个估算模型可以适用于所有类型的软件和开发环境。要根据项目的特点选择合理的估算模型。,14,2.1 静态单变量模型,这类模型的总体结构形式如下 E=A+B(ev)C其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量（KLOC或FP）。下面给出几个典型的静态单变量模型。1. 面向KLOC的估算模型(1) Walston_F
8、elix模型 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模型（在KLOC9时适用） E=5.288(KLOC)1.047,15,2.1 静态单变量模型,2. 面向FP的估算模型（自学）(1) Albrecht & Gaffney模型 E=-39+0.0545FP(2) Maston,Barnett和Mellichamp模型 E=585.7+15.12FP,16,2.2 动态多变量模型,动态多变量模型也称为软件方程式，它是根据从4000多个当代软件项目中收
9、集的生产率数据推导出来的。该模型把工作量看作是软件规模和开发时间这两个变量的函数。其表达形式如下： E=(LOCB0.333/P)3(1/t)4其中，E是以人月或人年为单位的工作量；t是以月或年为单位的项目持续时间；,17,2.2 动态多变量模型,B是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=515），B=0.16,对于超过70 KLOC的程序，B=0.39;P生产率参数，它反映了下述因素对工作量的影响： 总体过程成熟度及管理水平；使用良好的软件工程实践的程度；使用的程序设计语言的级别；软件环境的状态；软件项目组的技术及经验；应用系统
10、的复杂程度。,18,2.2 动态多变量模型,开发实时嵌入式软件时，P的典型值为2000；开发电信系统和系统软件时，P=10000；对于商业应用系统来说，P=28000。可以从历史数据导出适用于当前项目的生产率参数值。开发同一个软件（即LOC固定）的时候，如果把项目持续时间延长一些，则可降低完成项目所需的工作量。,和时间成反比,19,2.3 COCOMO2模型（自学）,COCOMO是构造性成本模型（constructive cost model)的英文缩写。1981年Boehm在软件工程经济学中首次提出了COCOMO模型。1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型
11、的修订版，它反映了十多年来在成本估计方面所积累的经验。,20,2.3 COCOMO2模型,COCOMO2给出了3个层次的软件开发工作量估算模型。这3个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。这些模型既可以用于不同类型的项目，也可以用于同一个项目的不同开发阶段。,21,2.3 COCOMO2模型,这3个层次的估算模型分别是： （1） 应用系统组成模型。它主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。（2） 早期设计模型。这个模型适用于体系结构设计阶段。（3） 后体系结构模型。这个模型适用于完成体系结构设计之后的软件开发阶段。,22,2.3 COCO
12、MO2模型,以后体系结构模型为例，介绍COCOMO2模型。该模型把软件开发工作量表示成代码行数（KLOC）的非线性函数： E=(3)E是开发工作量（以人月为单位），a是模型系数，KLOC是估计的源代码行数（以千行为单位），b是模型指数，fi(i=117)是成本因素。,23,2.3 COCOMO2模型,工作量方程中模型系数a的典型值为3.0，在实际工作中应该根据历史经验数据确定一个适合本组织当前开发的项目类型的数值。,24,2.3 COCOMO2模型,为了确定工作量方程中模型指数b的值，原始的COCOMO模型把软件开发项目划分成组织式、半独立式和嵌入式这样3种类型，并指定每种项目类型所对应的b值
13、（分别是1.05，1.12和1.20）。COCOMO2采用了更加精细得多的b分级模型，这个模型使用5个分级因素Wi(1i5),其中每个因素都划分成从甚低（Wi=5)到特高（Wi=0)的6个级别，然后用下式计算b的数值：b=b的取值范围为1.011.26。这种分级模式比原始COCOMO模型的分级模式更精细、更灵活。,25,2.3 COCOMO2模型,COCOMO2使用的5个分级因素如下所述： （1） 项目先例性。该因素指出，对于开发组织来说该项目的新奇程度。诸如开发类似系统的经验，需要创新体系结构和算法，以及需要并行开发硬件和软件等因素的影响，都体现在这个分级因素中。（2） 开发灵活性。这个分级
14、因素反映出，为了实现预先确定的外部接口需求及为了及早开发出产品而需要增加的工作量。,26,2.3 COCOMO2模型,（3） 风险排除度。这个分级因素反映了重大风险已被消除的比例。在多数情况下，这个比例和指定了重要模块接口（即选定了体系结构）的比例密切相关。（4） 项目组凝聚力。这个分级因素表明了开发人员相互协作时可能存在的困难。这个因素反映了开发人员在目标和文化背景等方面相一致的程度，以及开发人员组成一个小组工作的经验。（5） 过程成熟度。这个分级因素反映了按照能力成熟度模型度量出的项目组织的过程成熟度。,27,2.3 COCOMO2模型,每个成本因素都根据它的重要程度和对工作量影响大小被赋
15、予一定数值（称为工作量系数）。这些成本因素对任何一个项目的开发工作量都有影响，即使不使用COCOMO2模型估算工作量，也应该重视这些因素。Boehm把成本因素划分成产品因素、平台因素、人员因素和项目因素等4类。与原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述变化：,28,2.3 COCOMO2模型,（1） 新增加了4个成本因素。即可重用性、需要的文档量、人员连续性（即人员稳定程度）和多地点开发。这个变化表明，这些因素对开发成本的影响日益增加。（2） 略去了原始模型中的2个成本因素（计算机切换时间和使用现代程序设计实践）。并且在COCOMO2工作量方程的指数b中考虑了这个因素
16、的影响。（3） 调整成本因素的影响力。某些成本因素（分析员能力、平台经验、语言和工具经验）对生产率的影响（即工作量系数最大值与最小值的比率）增加了，另一些成本因素（程序员能力）的影响减小了。,29,3 进度计划,实际软件项目中，在实现一个大目标之前往往必须完成数以百计的小任务。一些任务处于“关键路径”之外，其完成时间如果没有严重拖后，都不会影响项目的完成时间；另一些任务处于“关键路径”之中，如果这些“关键任务”的进度拖后，则整个项目的完成日期就会拖后。管理人员应该高度关注关键任务的进展情况。,30,3 进度计划,一个有效的软件过程应该定义一个适用于当前项目的任务集合。一个任务集合包括一组软件工
17、程工作任务、里程碑和可交付的产品。为一个项目所定义的任务集合，必须包括为获得高质量的软件产品而应该完成的所有任务，但是同时又不能让项目组承担不必要的工作。项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。为达到上述目标，管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。,31,3.1 估算开发时间,估算出完成给定项目所需的总工作量之后，接下来需要回答：用多长时间才能完成该项目的开发工作？对于一个估计工作量为20人月的项目，可能想出下列几种进度表：1个人用20个月完成该项目；4个人用5个月完成该项目；20个人用1个月完成
18、该项目。但是，这些进度表并不现实，实际上软件开发时间与从事开发工作的人数之间并不是简单的反比关系。,32,3.1 估算开发时间,成本估算模型也同时提供了估算开发时间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是开发时间（以月为单位）。,33,3.1 估算开发时间,用上列方程计算出的T值，代表正常情况下的开发时间。客户往往希望缩短软件开发时间，显然，为了缩短
19、开发时间应该增加从事开发工作的人数。但是，随着开发小组规模扩大，个人生产率将下降，以致开发时间与从事开发工作的人数并不成反比关系。出现此种情况的原因：,34,3.1 估算开发时间,当小组变得更大时，增加了通信开销。当小组变得更大时，新成员在开始时不仅不是生产力，而且在他们学习期间还需要花费小组其他成员的时间。因此，存在被称为Brooks规律的下述现象： 向一个已经延期的项目增加人力，只会使得它更加延期。,35,3.1 估算开发时间,Boehm根据经验指出，软件项目的开发时间最多可以减少到正常开发时间的75%。如果要求一个软件系统的开发时间过短，则开发成功的概率几乎为零。,36,3.2 Gant
20、t图,Gantt（甘特）图是历史悠久、应用广泛的制定进度计划的工具。假设有一座陈旧的矩形木板房需要重新油漆。这项工作必须分3步完成： 首先刮掉旧漆，然后刷上新漆，最后清除溅在窗户上的油漆。假设一共分配了15名工人去完成这项工作，然而工具却很有限：只有5把刮旧漆用的刮板，5把刷漆用的刷子，5把清除溅在窗户上的油漆用的小刮刀。怎样安排才能使工作进行得更有效呢?,37,3.2 Gantt图,一种做法是首先刮掉四面墙壁上的旧漆，然后给每面墙壁都刷上新漆，最后清除溅在每个窗户上的油漆。显然这是效率最低的做法，因为总共有15名工人，然而每种工具却只有5件，这样安排工作在任何时候都有10名工人闲着没活干。所
21、以，应该采用“流水作业法”。,工厂流水线,38,3.2 Gantt图,假设木板房的第2、4两面墙的长度比第1、3两面墙的长度长一倍，此外，不同工作需要用的时间长短也不同，刷新漆最费时间，其次是刮旧漆，清理(即清除溅在窗户上的油漆)需要的时间最少。表5列出了估计每道工序需要用的时间。可以使用图1中的Gantt图描绘上述流水作业过程。,39,3.3 工程网络,Gantt图能很形象地描绘任务分解情况，以及每个子任务的开始时间和结束时间，因此是进度计划和进度管理的有力工具。它具有直观简明和容易掌握、容易绘制的优点，但是Gantt图也有3个主要缺点： (1) 不能显式地描绘各项作业彼此间的依赖关系；(2
22、) 进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象；(3) 计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。,40,3.3 工程网络,工程网络是制定进度计划时另一种常用的图形工具，它同样能描绘任务分解情况以及每项作业的开始时间和结束时间。此外，它还显式地描绘各个作业彼此间的依赖关系。因此，工程网络是系统分析和系统设计的强有力的工具。,41,3.3 工程网络,在工程网络中用箭头表示作业(例如，刮旧漆，刷新漆，清理等)，用圆圈表示事件(一项作业开始或结束)。事件是明确定义的时间点，它并不消耗时间和资源。作业通常既消耗资源又需要持续一定时间。,42,3.3 工程网络,在工
23、程网络中的一个事件，如果既有箭头进入又有箭头离开，则它既是某些作业的结束又是另一些作业的开始。例如，图2中事件2既是作业12(刮第1面墙上的旧漆)的结束，又是作业23(刮第2面墙上旧漆)和作业24(给第1面墙刷新漆)的开始。即只有第1面墙上的旧漆刮完之后，才能开始刮第2面墙上旧漆和给第1面墙刷新漆这两个作业。因此，工程网络显式地表示了作业之间的依赖关系。,43,3.3 工程网络,在图2中还有一些虚线箭头，它们表示虚拟作业，也就是事实上并不存在的作业。引入虚拟作业是为了显式地表示作业之间的依赖关系。例如，事件4既是给第1面墙刷新漆结束，又是给第2面墙刷新漆开始(作业46)。但是，在开始给第2面墙
24、刷新漆之前，不仅必须已经给第1面墙刷完了新漆，而且第2面墙上的旧漆也必须已经刮净(事件3)。也就是说，在事件3和事件4之间有依赖关系，或者说在作业23(刮第2面墙上旧漆)和作业46(给第2面墙刷新漆)之间有依赖关系，虚拟作业34明确地表示了这种依赖关系。虚拟作业既不消耗资源也不需要时间。,44,3.4 估算工程进度,画出类似图2那样的工程网络之后，系统分析员就可以借助它的帮助估算工程进度了。为此需要在工程网络上增加一些必要的信息。首先，把每个作业估计需要使用的时间写在表示该项作业的箭头上方。注意，箭头长度和它代表的作业持续时间没有关系，箭头仅表示依赖关系，它上方的数字才表示作业的持续时间。,4
25、5,3.4 估算工程进度,其次，为每个事件计算下述两个统计数字： 最早时刻EET和最迟时刻LET。这两个数字将分别写在表示事件的圆圈的右上角和右下角。事件的最早时刻是该事件可以发生的最早时间。工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。计算最早时刻EET使用下述3条简单规则：,46,15-8-4=3,15,8,4,47,3.4 估算工程进度,(1) 考虑进入该事件的所有作业；(2) 计算每个作业的持续时间与起始事件的EET之和；(3) 选取上述和数中的最大值作为该事件的最早时刻EET。,48,3.4 估算工程进度,事件的最迟时刻是在不影响工
26、程竣工时间的前提下，该事件最晚可以发生的时刻。最后一个事件(工程结束)的最迟时刻就是它的最早时刻。其他事件的最迟时刻在工程网络上从右至左按逆作业流的方向计算。计算最迟时刻LET使用下述3条规则： (1) 考虑离开该事件的所有作业；(2) 从每个作业的结束事件的最迟时刻中减去该作业的持续时间；(3) 选取上述差数中的最小值作为该事件的最迟时刻LET。,49,3.5 关键路径,图中有几个事件的最早时刻和最迟时刻相同，这些事件定义了关键路径。关键路径上的事件必须准时发生，组成关键路径的作业的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。项目管理人员应该注视关键作业的进展情况，如果关键事
27、件出现的时间比预计的时间晚，则会使最终完成项目的时间拖后；如果希望缩短工期，只有往关键作业中增加资源才会有效果。,50,3.6 机动时间,不在关键路径上的作业有一定程度的机动余地实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些，而并不影响工程的结束时间。一个作业可以有的全部机动时间： 机动时间=(LET)结束-(EET)开始-持续时间对于前述油漆旧木板房的例子，计算得到的非关键作业的机动时间列在表6中。,51,3.6 机动时间,在工程网络中每个作业的机动时间写在代表该项作业的箭头下面的括弧里。在制定进度计划时仔细考虑和利用工程网络中的机动时间，往往能够安排出既节省资
28、源又不影响最终竣工时间的进度表。在图4中的Gantt图描绘了其中的一种方案。,52,3.6 机动时间,这个例子说明了工程网络比Gantt图优越的地方： 它显式地定义事件及作业之间的依赖关系，Gantt图只能隐含地表示这种关系。但是Gantt图的形式比工程网络更简单更直观，为更多的人所熟悉，因此，应该同时使用这两种工具制订和管理进度计划，使它们互相补充取长补短。,53,3.6 机动时间,第2节中介绍的工作量估计技术可以帮助我们估计每项任务的工作量，根据人力分配情况，可以进一步确定每项任务的持续时间。从这些基本数据出发，根据作业之间的依赖关系，利用工程网络和Gantt图可以制定出合理的进度计划，并
29、且能够科学地管理软件开发工程的进展情况。,54,4 人员组织（自学）,软件项目成功的关键是有高素质的软件开发人员。大多数软件的规模都很大，单个软件开发人员无法在给定期限内完成开发工作，因此，必须把多名软件开发人员合理地组织起来，使他们有效地分工协作共同完成开发工作。为了成功地完成软件开发工作，项目组成员必须以一种有意义且有效的方式彼此交互和通信。,55,4 人员组织,如何组织项目组是一个重要的管理问题，管理者应合理组织项目组，使其有较高生产率，能够按预定的进度计划完成所承担的工作。项目组组织得越好，其生产率越高，而且产品质量也越好。每个管理者的目标都是建立有凝聚力的项目组。一个有高度凝聚力的小
30、组，由一批团结得非常紧密的人组成，他们的整体力量大于个体力量的总和。一旦项目组具有了凝聚力，成功的可能性就大大增加了。,56,4 人员组织,现有的软件项目组的组织方式很多，通常，组织软件开发人员的方法，取决于所承担的项目的特点、以往的组织经验以及管理者的看法和喜好。下面介绍3种典型的组织方式。民主制程序员组主程序员组现代程序员组,57,4.1 民主制程序员组,民主制程序员组的一个重要特点是小组成员完全平等，享有充分民主，通过协商做出技术决策。小组成员之间的通信是平行的，如果小组内有n个成员，则可能的通信信道共有n(n-1)/2条。程序设计小组的人数不能太多。通信信道的维护难度增加；测试和软件接
31、口的复杂性增加；,大家都有发言权,58,4.1 民主制程序员组,程序设计小组的规模以28名成员为宜。若项目规模很大,用一个小组不能在预定时间内完成开发任务,则应该使用多个程序设计小组。系统的总体设计应该能够保证由各个小组负责开发的各部分之间的接口是良好定义的,并且是尽可能简单的。小组规模小,不仅可以减少通信问题,而且还有其他好处。例如,容易确定小组的质量标准,而且用民主方式确定的标准更容易被大家遵守;组员间关系密切,能够互相学习等等。,59,4.1 民主制程序员组,民主制程序员组通常采用非正式的组织方式，也就是说，虽然名义上有一个组长，但是他和组内其他成员完成同样的任务。在这样的小组中，由全体
32、讨论协商决定应该完成的工作，并且根据每个人的能力和经验分配适当的任务。民主制程序员组的主要优点是，组员们对发现程序错误持积极的态度，这种态度有助于更快速地发现错误，从而导致高质量的代码。,60,4.1 民主制程序员组,民主制程序员组的另一个优点是，组员们享有充分民主，小组有高度凝聚力，组内学术空气浓厚，有利于攻克技术难关。因此，当有难题需要解决时，也就是说，当所要开发的软件的技术难度较高时，采用民主制程序员组是适宜的。如果组内多数成员是经验丰富技术熟练的程序员,那么上述非正式的组织方式可能会非常成功。在这样的小组内组员享有充分民主,通过协商,在自愿的基础上作出决定,因此能够增强团结、提高工作效
33、率。,61,4.1 民主制程序员组,如果组内多数成员技术水平不高,或是缺乏经验的新手,那么这种非正式的组织方式也有严重缺点： 由于没有明确的权威指导开发工程的进行,组员间将缺乏必要的协调,最终可能导致工程失败。为了使少数经验丰富、技术高超的程序员在软件开发过程中能够发挥更大作用，程序设计小组也可以采用下面的另外一种组织形式。,62,4.2 主程序员组,美国IBM公司在20世纪70年代初期开始采用主程序员组的组织方式。采用这种组织方式主要出于下述几点考虑： (1) 软件开发人员多数比较缺乏经验；(2) 程序设计过程中有许多事务性的工作，例如，大量信息的存储和更新；(3) 多渠道通信很费时间，将降
34、低程序员的生产率。,63,4.2 主程序员组,主程序员组用经验多、技术好、能力强的程序员作为主程序员，同时，利用人和计算机在事务性工作方面给主程序员提供充分支持，而且所有通信都通过一两个人进行。这种组织方式类似于外科手术小组的组织： 主刀大夫对手术全面负责，并且完成制订手术方案、开刀等关键工作，同时又有麻醉师、护士长等技术熟练的专门人员协助和配合他的工作。此外，必要时手术组还要请其他领域的专家协助。,64,4.2 主程序员组,主程序员组的两个重要特性： （1） 专业化。该组每名成员仅完成他们受过专业训练的那些工作。（2） 层次性。主刀大夫指挥每名组员工作，并对手术全面负责。典型的主程序员组的组
35、织形式如图5所示。该组由主程序员、后备程序员、编程秘书以及13名程序员组成。在必要的时候，该组还有其他领域的专家协助。,65,4.2 主程序员组,管理者兼构架师,主程序员的替补,主程序员的助手,代码编写者,66,4.2 主程序员组,主程序员组核心人员的分工如下： （1） 主程序员既是成功的管理人员又是经验丰富、技术好、能力强的高级程序员，负责体系结构设计和关键部分的详细设计，并且负责指导其他程序员完成详细设计和编码工作。程序员之间没有通信渠道，所有接口问题都由主程序员处理。主程序员对每行代码的质量负责，因此，他还要对组内其他成员的工作成果进行复查。,67,4.2 主程序员组,（2） 后备程序员
36、也应该技术熟练而且富于经验，他协助主程序员工作并且在必要时接替主程序员的工作。平时，后备程序员的工作主要是设计测试方案、分析测试结果及独立于设计过程的其他工作。（3） 编程秘书负责完成与项目有关的全部事务性工作，例如，维护项目资料库和项目文档，编译、链接、执行源程序和测试用例。,68,4.2 主程序员组,虽然图5所示的主程序员组的组织方式说起来有不少优点，但是，它在许多方面却是不切实际的。首先，主程序员应该是高级程序员和优秀管理者的结合体。在现实社会中这样的人才并不多见。其次，后备程序员更难找。第三，编程秘书也很难找到。专业的软件技术人员一般都厌烦日常的事务性工作，,69,4.3 现代程序员组
37、,民主制程序员组的一个优点是小组成员都对发现程序错误持积极、主动的态度。但是，使用主程序员组的组织方式时，主程序员对每行代码的质量负责，因此，他必须参与所有代码审查工作。由于主程序员同时又是负责对小组成员进行评价的管理员，他参与代码审查工作就会把所发现的程序错误与小组成员的工作业绩联系起来，从而造成小组成员出现不愿意发现错误的心理。,70,4.3 现代程序员组,可以取消主程序员的大部分行政管理工作。于是，实际的“主程序员”应该由两个人共同担任： 一个技术负责人，负责小组的技术活动；一个行政负责人，负责所有非技术性事务的管理决策。如图6所示。技术组长自然要参与全部代码审查工作，因为他要对代码的各
38、方面质量负责；相反，行政组长不可以参与代码审查工作，因为他的职责是对程序员的业绩进行评价。行政组长应该在常规调度会议上了解每名组员的技术能力和工作业绩。,71,4.3 现代程序员组,72,4.3 现代程序员组,在开始工作之前明确划分技术组长和行政组长的管理权限是很重要的。注意协调。例如，考虑年度休假问题，行政组长有权批准某个程序员休年假的申请，因为这是一个非技术性问题，但是技术组长可能马上否决了这个申请，因为已经接近预定的项目结束日期，目前人手非常紧张。解决这类问题的办法是求助于更高层的管理人员，对行政组长和技术组长都认为是属于自己职责范围内的事务，制定一个处理方案。,73,4.3 现代程序员
39、组,由于程序员组成员人数不宜过多，当软件项目规模较大时，应该把程序员分成若干个小组，如图7所示。该图描绘的是技术管理组织结构，非技术管理组织结构与此类似。由图可以看出，产品开发作为一个整体是在项目经理的指导下进行的，程序员向他们的组长汇报工作，而组长则向项目经理汇报工作。当产品规模更大时，可以适当增加中间管理层次。,74,4.3 现代程序员组,75,4.3 现代程序员组,把民主制程序员组和主程序员组的优点结合起来的另一种方法，是在合适的地方采用分散做决定的方法，如图8所示。这样做有利于形成畅通的通信渠道，以便充分发挥每个程序员的积极性和主动性，集思广益攻克技术难关。这种组织方式对于适合采用民主
40、方法的那类问题（例如，研究性项目或遇到技术难题需要用集体智慧攻关）非常有效。尽管这种组织方式适当地发扬了民主，但是上下级之间的箭头（即管理关系）仍然是向下的，也就是说，是在集中指导下发扬民主。显然，如果程序员可以指挥项目经理，则只会引起混乱。,76,4.3 现代程序员组,77,5 质量保证 5.1 软件质量,软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。上述定义强调了下述的3个要点：,78,5.1 软件质量,（1） 软件需求是度量软件质量的基础，与需求不
41、一致就是质量不高。（2） 指定的开发标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致软件质量不高。（3） 有一组没有显式描述的隐含需求（例如，软件应该是容易维护的）。如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。,79,5.1 软件质量,可以把这些质量因素分成3组，分别反映用户在使用软件产品时的3种不同倾向或观点。这3种倾向是： 产品运行、产品修改和产品转移。,80,81,5.2 软件质量保证措施,软件质量保证（software quality assurance,SQA）的措施主要有： 基于非执行的测试（也称为复审或评审），基于执行的
42、测试（即以前讲过的软件测试）和程序正确性证明。,82,5.2 软件质量保证措施,复审保证在编码之前各阶段产生的文档的质量；基于执行的测试需要在程序编写出来之后进行，它是保证软件质量的最后一道防线；程序正确性证明使用数学方法严格验证程序是否与对它的说明完全一致。,83,5.2 软件质量保证措施,参加软件质量保证工作的人员，可以划分成下述两类： 软件工程师：通过采用先进的技术方法和度量，进行正式的技术复审以及完成计划周密的软件测试来保证软件质量。SQA小组：辅助软件工程师以获得高质量的软件产品。其从事的软件质量保证活动主要是：计划，监督，记录，分析和报告。SQA小组的作用是，通过确保软件过程的质量
43、来保证软件产品的质量。,84,5.2 软件质量保证措施,1. 技术复审的必要性正式技术复审的显著优点是较早发现软件错误，从而可防止错误被传播到软件过程的后续阶段。统计数字表明，在大型软件产品中检测出的错误，60%70%属于规格说明错误或设计错误，而正式技术复审在发现规格说明错误和设计错误方面的有效性高达75%。正式技术复审是软件质量保证措施的一种包括走查（walkthrough)和审查（inspection）。走查的步骤比审查少，而且没有审查正规。,85,5.2 软件质量保证措施,2. 走查走查组由46名成员组成。以走查规格说明的小组为例，包括一名负责起草规格说明的人一名负责该规格说明的管理员
44、一位客户代表下阶段开发组（在本例中是设计组）的一名代表SQA小组的一名代表。SQA小组的代表应该作为走查组的组长。必须把被走查的材料预先分发给走查组每位成员。走查组成员应该仔细研究材料并列出两张表：一张表是他不理解的术语，另一张是他认为不正确的术语。,86,5.2 软件质量保证措施,走查组的任务仅仅是标记出错误而不是改正错误，改正错误的工作应该由该文档的编写组完成。走查的时间最长不要超过2小时，这段时间应该用来发现和标记错误，而不是改正错误。,87,5.2 软件质量保证措施,走查主要有下述两种方式： （1） 参与者驱动法。参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档
45、编写组的代表必须回答每个质疑，要么承认确实有错误，要么对质疑做出解释。（2） 文档驱动法。文档编写者向走查组成员仔细解释文档。走查组成员在此过程中不时针对事先准备好的问题或解释过程中发现的问题提出质疑。这种方法可能比第一种方法更有效，往往能检测出更多错误。经验表明，使用文档驱动法时许多错误是由文档讲解者自己发现的。,88,5.2 软件质量保证措施,3. 审查审查的范围比走查广泛得多，通常，审查过程包括下述5个基本步骤： （1） 综述。由负责编写文档的一名成员向审查组综述该文档。在综述会结束时把文档分发给每位与会者。（2） 准备。评审员仔细阅读文档。最好列出在审查中发现的错误的类型，并按发生频率
46、把错误类型分级，以辅助审查工作。这些列表有助于评审员们把注意力集中到最常发生错误的区域。,89,5.2 软件质量保证措施,（3） 审查。评审组仔细走查整个文档。和走查一样，这一步的目的也是发现文档中的错误，而不是改正它们。通常每次审查会不超过90分钟。审查组组长应该在一天之内写出一份关于审查的报告。（4） 返工。文档的作者负责解决在审查报告中列出的所有错误及问题。（5） 跟踪。组长必须确保所提出的每个问题都得到了圆满的解决（要么修正了文档，要么澄清了被误认为是错误的条目）。必须仔细检查对文档所做的每个修正，以确保没有引入新的错误。如果在审查过程中返工量超过5%，则应该由审查组再对文档全面地审查
47、一遍。,90,5.2 软件质量保证措施,通常，审查组由4人组成。组长既是审查组的管理人员又是技术负责人。审查组必须包括负责当前阶段开发工作的项目组代表和负责下一阶段开发工作的项目组代表，此外，还应该包括一名SQA小组的代表。审查过程不仅步数比走查多，而且每个步骤都是正规的。审查的正规性体现在：仔细划分错误类型，并把这些信息运用在后续阶段的文档审查中以及未来产品的审查中。,91,5.2 软件质量保证措施,审查是检测软件错误的一种好方法，利用审查可以在软件过程的早期阶段发现并改正错误，也就是说，能在修正错误的代价变得很昂贵之前就发现并改正错误。因此，审查是一种经济有效的错误检测方法。,92,5.2
48、 软件质量保证措施,4. 程序正确性证明（自学）测试是保证软件可靠性的重要手段；但是，测试只能证明程序中有错误，并不能证明程序中没有错误。对于保证软件可靠性来说，测试是一种不完善的技术，人们自然希望研究出完善的正确性证明技术。一旦研究出实用的正确性证明程序，软件可靠性将更有保证，测试工作量将大大减少。程序正确性证明只证明程序功能是正确的，并不能证明程序的动态特性是符合要求的，此外，正确性证明过程本身也可能发生错误。,93,5.2 软件质量保证措施,正确性证明的基本思想是证明程序能完成预定的功能。因此，应该提供对程序功能的严格数学说明，然后根据程序代码证明程序确实能实现它的功能说明。在20世纪60年代初期，人们已经开始研究程序正确性证明的技术，提出了许多不同的技术方法。虽然这些技术方法本身很复杂，但是它们的基本原理却是相当简单的。,94,5.2 软件质量保证措施,如果在程序的若干个点上，设计者可以提出关于程序变量及它们的关系的断言，那么在每一点上的断言都应该永远是真的。假设在程序的P1,P2,，Pn等点上的断言分别是a(1),a(2)，a(n)，其中a(1)必须是关于程序输入的断言，a(n)必须是关于程序输出的断言。,
