第四篇 软件项目管理

第10章 计划 退出 所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。 第10章 计划 所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。 软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。 软件项目管理过程从一组称为项目计划的活动开始，而第一项计划活动是“估算”。 退出

软件计划最详尽地描述了软件过程，它包括采用的生命周期模型、开发组织的组织结构、责任分配、管理目标和优先级、所用的技术和CASE工具，以及详细的进度、预算和资源分配。整个计划的基础是工作量估算和完成期限估算。

10.1 度量软件规模 10.2 工作量估算 10.3 进度计划 10.4 小结

10.1 度量软件规模 10.1.1 代码行技术 代码行技术是比较简单的定量估算软件规模的方法。这种方法根据以往开发类似产品的经验和历史数据，估计实现一个功能需要的源程序行数。当有以往开发类似项目的历史数据可供参考时，用这种方法估计出的数据还是比较准确的。把实现每个功能需要的源程序行数累加起来，就得到实现整个软件需要的源程序行数。

为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别作出估计。每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出  用代码行技术度量软件规模时，当程序较小时常用的单位是代码行数(LOC)，当程序较大时常用的单位是千行代码数(KLOC)。

10.1.2 功能点技术 功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点(FP)为单位，度量软件的规模。 1. 信息域特性 功能点技术定义了信息域的5个特性，分别是输入项数(Inp)、输出项数(Out)、查询数(Inq)，主文件数(Maf)和外部接口数(Inf)。

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

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

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

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

10.2.1 静态单变量模型 这类模型的总体结构形式如下： E=A+B×(ev) C 其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量(LOC或FP)。此外，大多数模型都有某种形式的调整成分，使得E能够依据项目的其他特性(例如，问题的复杂程度、开发人员的经验、开发环境等)加以调整。下面给出几个典型的静态单变量模型。

1. 面向LOC的估算模型 (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.407

2面向FP的估算模型 (1) Albrecht & Gaffney模型 E=-13.39+0.0545FP (2) Kemerer模型 E=60.62×7.728×10-8FP3 (3) Maston、Barnett和Mellichamp模型 E=585.7+5.12FP

10.2.2 动态多变量模型 动态多变量模型也称为软件方程式，它是根据从4000多个当代软件项目中收集的生产率数据推导出来的。这种模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下： E=〔LOC×B0.333/P〕3×(1/t) 4 其中， E是以人月或人年为单位的工作量； t是以月或年为单位的项目持续时间； B是“特殊技术因子”，它随着对集成、测试、质量保证、文档及管理技术的需求的增长而缓慢增加，对于较小的程序(KLOC=5～10)，B=0.16，对于超过70KLOC的程序，B=0.39； P是“生产率参数”，它反映了下述因素对工作量的影响：

· 总体的过程成熟度及管理水平； · 使用良好的软件工程实践的程度； · 使用的程序设计语言的级别； · 软件环境的状态； · 软件项目组的技术及经验； · 应用系统的复杂程度。

当开发实时嵌入式软件时，典型值是P=2000；对于电信和系统软件来说，P=10000；对于商业系统应用，P=28000。适用于当前项目的生产率参数，可以从历史数据导出。 应该注意，软件方程式有两个独立的变量：①对软件规模的估算值(用LOC表示)；②以月或年为单位的项目持续时间。 从(10.2)式可以看出，开发同一个软件(即LOC固定)的时候，如果把项目持续时间延长一些，则可降低完成项目所需要的工作量。

10.2.3 COCOMO模型 所谓COCOMO模型就是Boehm提出的构造性成本模型(COnstructive COst MOdel)，它是一种层次结构的软件估算模型。 下面以中级COCOMO模型为例，介绍构造性成本模型。该模型把软件开发工作量表示成代码行数(KLOC)的非线性函数：

其中 MM是开发工作量(以人月为单位)， C1是模型系数， KLOC是估计的代码行数(以千行为单位)， a是模型指数， fi(i=1到15)是成本因素。 每个成本因素都根据它的重要程度和影响大小赋予一定数值。成本因素影响所有工程项目，即使不使用COCOMO模型估算成本，也应该注意这些因素。可以把成本因素划分成产品因素、计算机因素、人员因素和项目因素等，下面简单介绍主要的成本因素。 1. 产品因素 (1) 要求的软件可靠性(RELY)

(2) 数据库规模(DATA) (3) 软件产品复杂程度(CPLX) 2. 计算机因素 (1) 执行时间的约束(TIME) (2) 存储约束(STOR) (3) 环境变更率(VIRT) (4) 计算机换向时间(TURN)

3. 人员因素 (1) 系统分析员的能力(ACAP) (2) 应用经验(AEXP) (3) 程序员的能力(PCAP) (4) 环境知识(VEXP) (5) 语言知识(LEXP)

4. 项目因素 (1) 程序设计实践(MODP) (2) 软件工具(TOOL) (3) 进度约束(SCED)

软件开发项目可以分成组织式、半独立式和嵌入式三种模式。对组织式软件的要求通常不苛刻，开发人员经验丰富，而且对软件的使用环境很熟悉(通常是为自己所在的组织开发软件)，程序规模一般不大(小于50000行代码)。例如，简单的商业数据处理系统即属于组织式。嵌入式软件需要在很强的约束条件下运行，通常和某些硬设备紧密结合在一起(例如，空中交通管理软件)，对这类软件系统的要求通常十分苛刻。对半独立式软件的要求通常介于上述两类软件之间，但是这类软件的规模一般都比较大(可达300000行代码)。

表10. 3列出了上述三种开发模式的模型系数和模型指数。表10 表10.3列出了上述三种开发模式的模型系数和模型指数。表10.4列出了各个成本因素的实际值(称为工作量系数)。有了这两张表中的数据，就可以用式(10.3)估算工作量了。

对64个覆盖了相当广泛的应用领域的项目样本的研究，证明了中级COCOMO模型的有效性：对这些样本应用该模型，预测结果的误差在20%以内的项目约占总项目的68%。

10.3 进度计划 项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。为了做到这一点，管理者必须制定一个足够详细的进度表，以便监督项目进度，并控制整个项目。 软件项目的进度安排是一项活动，它通过把工作量分配给特定的软件工程任务，并规定完成各项任务的起、止日期，从而将估算的工作量分布于计划好的项目持续期内。

10.3.1 基本原则 下述的基本原则能够指导软件项目的进度安排。 1. 划分 2. 相互依赖性 3. 时间分配 4. 工作量确认 5. 定义责任 6. 定义结果 7. 定义里程碑

10.3.2 Gantt图 Gantt图(甘特图)是历史悠久、应用广泛的进度计划工具，下面通过一个非常简单的例子介绍这种工具。

图10.1 旧木板房刷漆工程的Gantt图 为了醒目地表示里程碑，可以在Gantt图中加上菱形标 记，一个菱形代表一个里程碑，如图10.2所示。

图10.2 标有里程碑的Gantt图

10.3.3 工程网络 上一小节介绍的Gantt图能很形象地描绘任务分解情况，以及每个子任务(作业)的开始时间和结束时间，因此是进度计划和进度管理的有力工具。它具有直观简明和容易掌握、容易绘制的优点，但是Gantt图也有三个主要缺点： · 不能显式地描绘各项作业彼此间的依赖关系； · 进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象； · 计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。

当把一个工程项目分解成许多子任务，并且它们彼此间的依赖关系又比较复杂时，仅仅用Gantt图作为安排进度的工具是不够的，不仅难于做出既节省资源又保证进度的计划，而且还容易发生差错。 工程网络是制定进度计划时另一种常用的图形工具，它同样能描绘任务分解情况以及每项作业的开始时间和结束时间，此外，它还显式地描绘各个作业彼此间的依赖关系。因此，工程网络是系统分析和系统设计的强有力的工具。

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

图中：1—2刮第1面墙上的旧漆；2—3刮第2面墙上的旧漆； 图10.3 旧木板房刷漆工程的工程网络 图中：1—2刮第1面墙上的旧漆；2—3刮第2面墙上的旧漆； 2—4给第1面墙刷新漆；3—5刮第3面墙上旧漆； 4—6给第2面墙刷新漆；4—7清理第1面墙窗户； 5—8刮第4面墙上旧漆；6—8给第3面墙刷新漆； 7—9清理第2面墙窗户；8—10给第4面墙刷新漆； 9—10清理第3面墙窗户；10—11清理第4面墙窗户； 虚拟作业：3—4；5—6；6—7；8—9。

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

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

10.3.4 估算进度 画出类似图10.3那样的工程网络之后，系统分析员就可以借助它的帮助估算工程进度了。为此需要在工程网络上增加一些必要的信息。 首先，把每个作业估计需要使用的时间写在表示该项作业的箭头上方。注意，箭头长度和它代表的作业持续时间没有关系，箭头仅表示依赖关系，它上方的数字才表示作业的持续时间。 其次，为每个事件计算下述两个统计数字：最早时刻EET和最迟时刻LET。这两个数字将分别写在表示事件的圆圈的右上角和右下角，如图10.4左下角的符号所示。

图10.4 旧木板房刷漆工程的完整的工程网络(粗线箭头是关键路径)

事件的最早时刻是该事件可以发生的最早时间。通常工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。计算最早时刻EET使用下述三条简单规则： · 考虑进入该事件的所有作业； · 对于每个作业都计算它的持续时间与起始事件的EET之和； · 选取上述和数中的最大值作为该事件的最早时刻EET。

事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻。按惯例，最后一个事件(工程结束)的最迟时刻就是它的最早时刻。其他事件的最迟时刻在工程网络上从右至左按逆作业流的方向计算。计算最迟时刻LET使用下述三条规则： ·考虑离开该事件的所有作业； · 从每个作业的结束事件的最迟时刻中减去该作业的持续时间； · 选取上述差数中的最小值做为该事件的最迟时刻LET。

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

机动时间=(LET)结束-(EET)开始-持续时间 10.3.6 机动时间 不在关键路径上的作业有一定程度的机动余地——实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预计的持续时间长一些，而并不影响工程的结束时间。一个作业可以有的全部机动时间等于它的结束事件的最迟时刻减去它的开始事件的最早时刻，再减去这个作业的持续时间： 机动时间=(LET)结束-(EET)开始-持续时间 对于前述油漆旧木板房的例子，计算得到的非关键作业的机动时间列在表10.6中。

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

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

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

度量软件规模的常用技术主要有代码行技术和功能点技术。这两种技术各有优缺点，应该根据软件项目的特点及项目计划者对这两种技术的熟悉程度，选用适用的技术。 根据项目的规模可以估算出完成项目所需的工作量，常用的估算模型有静态单变量模型、动态多变量模型和COCOMO模型。为了做到较准确的项目估算，通常至少同时使用上述三种模型中的两种。通过比较和协调使用不同模型得出的估算值，有可能得到比较准确的估算结果。虽然软件项目估算并不是一门精确的科学，但是，把可靠的历史数据和系统化的技术结合起来，仍然能够提高估算的准确度。

项目管理者的目标是定义所有项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能够及时发现拖延进度的情况。为此，管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。 常用的制定进度计划的工具主要有Gantt图和工程网络两种。Gantt图具有历史悠久、直观简明、容易学习、容易绘制等优点，但是，它不能显式地表示各项任务彼此间的依赖关系，也不能显式地表示关键路径和关键任务，进度计划中的关键部分不明确。因此，在管理大型软件项目时，仅用Gantt图是不够的，不仅难于做出既节省资源又保证进度的计划，而且还容易发生差错。

工程网络不仅能描绘任务分解情况及每项作业的开始时间和结束时间，而且还能显式地表示各个作业彼此间的依赖关系。从工程网络图中容易识别出关键路径和关键任务。因此，工程网络是制定进度计划的强有力的工具。通常，联合使用Gantt图和工程网络这两种工具来制定和管理进度计划，使它们互相补充、取长补短。