第四章 项目启动管理

王晓辉计算机科学与技术学院

软件项目进度计划编制案例

信息系统开发为例：加入该 MIS 开发的时间要求是 100~125

天，要求正式验收前要试运行 20 天以上。WBS 结构图项目工作关系表网络进度计划软件项目成本估算

工作分解结构图

110需求分析

120开发环境准备

130系统设计

140系统编码

150系统测试

160试运行

170用户验收

100管理信息系统开发

111需求调研

112需求分析

113需求确认

121硬件环境准备

122软件环境准备

131系统分析

132总体设计

133详细设计

141编码

142界面设计

151测试计划

152单元测试

153集成测试

161试运行

162试运行报告

163系统改进

项目工作关系表任务编码 任务名称 工作代号 前期工作 后续工作 持续天数 负责人

111用户需求

调研 A 112 10

112 需求分析 B 111 113 5

113 需求确认 C 112121 ， 13

15

121硬件环境

准备 D 113 122 2

122软件环境

确认 E 121 141 3

131 系统分析 F 113 132 10

132 总体设计 G 131 133 8

133 详细设计 H 132 141 12

141 编码 I122 ， 13

3151 20

…

如何估算？

网络进度计划图

ID

TF

FF

ES EF

LS LF

最早完成时间

最迟完成时间

最早开始时间

最迟开始时间

总时差LF-EF

自由时差(一般为0)

A

0

0

0 10

0 10

B

010 15

10 15

C

015 20

15 20

D

2520 22

45 47

E

2522 25

47 50

F

020 30

20 30

G

030 38

30 38

H

038 50

38 50

I

050 70

50 70

K

070 75

70 75

J

1250 58

0

70

L

075 85

75 85

M

085 93

85 93

N

093 108

93 108

P

0108 110

Q

0110 115

R

0115 120

62

108 110 110 115 115 120

0 0

0 0

00 0 0 0 0 0

0 0 0

0

0

0

试运行时间

网络图的 Visio 画法

持续时间 最早完成时间

最迟开始时间 淡季 最迟完成时间

最早开始时间

任务名称

实际开始时间 实际完成时间

预定完成时间预定开始时间

任务名称

进度图之——甘特图

ID 任务名称 开始时间 完成 持续时间2006年 12月

18 19 20 21 22 23 24 25 26 27 28 29 30 31

1 2d2006-12-192006-12-18任务 1

2 3d2006-12-222006-12-20任务 2

3 3d2006-12-262006-12-22任务 3

4 4d2006-12-282006-12-25任务 4

5 1d2006-12-292006-12-29任务 5

4.4 软件项目成本估算 常见的成本估算方法有如下的三种 :

标准值估算法Putman 方法COCOMO

4.4.1 值估算法 估算公式为 :

其中 ,A 是估算的最小规模 ,B 是最大规模 ,M是最可能的规模。

然后可以使用一些修正系数来估算工作量。修正系数 = 1+0.1*n （ n 为各种量化因子）是用于小型非常熟悉的系统。

6

4 BMA

4.4.2 Putman 模型估算法Putman 模型是一种动态多变量模型，根据 50 多个

大型项目导出的规律：

其中， L 是源代码行数； K 是工作量（人年）； t是开发所需要的时间（年）； C 为技术水平常数：

差的开发环境： C=2500

好的开发环境： C=10000

优越的开发环境： C=12500

3/43/1dK tKCL

Putman 模型

根据公式得到的工作量估算公式为：

比如：一个 2 年的项目，需要开发 100 万行的代码，开发环境优越，那么他需要的工作量为：

(100000**3 ) * (10000**(-3)) * (2**(-4))

约： 62.5 人年

433 dk tCLK

4.4.3 COCOMO 模型

该模型是 Boehm 提出的结构性成本估算模型，他将现有的项目分成了三种开发模式：

模式 产品规模 项目 /团队规模 革新 期限和约束 开发环境

组织型 2~50KLOC 小型项目 /团队 很少 不严格 稳定，内部

半独立型 50~300KLOC 中型项目 /团队 中等 中等 中等

嵌入型 大于 300KLOC 大型项目 /团队 许多 约束严格 复杂的硬件 /客户接口

COCOMO 模型的三个等级 基本 COCOMO

这个等级仅仅使用规模和模式来确定工作量和进度。它可以对小到中等规模的项目进行快速而粗略的评估。

中等 COCOMO 这个等级使用规模、模式和 15 个其他变量来确定工作

量。其他的变量被称为“成本驱动因子”，这些因子与产品、人员、计算机和增加或减少软件项工作量的项目属性相关。

详细 COCOMO 这个层次基于中等 COCOMO 之上，并且引入了其它

对阶段敏感的工作量系数以及一个 3 层产品结构。

4.4.3.1 基本 COCOMO

在基本 COCOMO 模型中，交付的源指令千行数（ KLOC ）是唯一的输入变量，并用它的一个指数公式来估算软件项目的工作量。

“ 工作量”的含义就是完成某项任务所需要的劳动量，在软件项目中通常使用“人员 - 月”来作为工作量的单位。

根据美国的节假日计算，每个人月包含 19 个人员 - 工作日，每个人员每天工作 8 小时， 1 个人月就包含 152 个人员 - 小时。在评估工作量时，单位一定要统一，不同的国家工作量的定义会有所区别。

基本 COCOMO 公式

工作量（ E ） = a× （规模） b

开发模式 a b 工作量公式

组织型 2.4 1.05 E = 2.4（ KLOC） 1.05

半独立型 3.0 1.12 E = 3.0（ KLOC） 1.12

嵌入型 3.6 1.20 E = 3.6（ KLOC） 1.20

基本 COCOMO 举例 假设估算项目规模是 200KLOC ，

当该项目是组织型的时候，工作量估算为 2.4（ 200 ） 1.05=2.4 （ 260.66 ） =626 人月。

当该项目是半独立型时，工作量估算为 3.0（ 200 ） 1.12=3.0 （ 377.71 ） =1 133 人月。

当该项目是嵌入型时，工作量估算为 3.6 （ 200 ） 1.20=3.6 （ 577 ） =2 077 人月。

基本 COCOMO 进度估算

其中， c 和 d 也是从回归分析中导出的常数， c 一般取 2.5 ，不同的开发模式 d 的取值也不同，在组织型模式中取 0.38 ，在半独立型模式中一般取 0.35 ，在嵌入型模式中可取 0.32 。

( )dTDEV c E

基本 COCOMO 进度估算公式

开发模式 工作量公式（单位：人月）

进度估算（单位：月）

组织型 E = 2.4（ KLOC） 1.05 TDEV=2.5(E)0.38

半独立型 E = 3.0（ KLOC） 1.12 TDEV=2.5(E)0.35

嵌入型 E = 3.6（ KLOC） 1.20 TDEV=2.5(E)0.32

基本 COCOMO 全职人月估算

得出了工作量（ E ，单位“人员 -月”）和开发时间（ TDEV ，单位“月”）之后，就可以计算完成项目的平均全职人员（ FSP ， Full-time-equivalent Software Personnel ，单位“人员”）数了。其计算公式为：

FSP = E / TDEV

基本 COCOMO 效率估算

在求得了开发时间后，我们又可以对平均的生产效率进行估算，生产效率用 P 表示，单位是 LOC/ 人月，其估算公式为：

P = KLOC / E

COCOMO 估算例

一个 32KLOC 的中型项目： 工作量： E=2.4 （ 32 ） 1.05 = 91 人月生产率：

进 度： TDEV = 2.5 （ 91 ） 0.38 = 14 个月

平均安置人员：

32000352

91

DSI DSI

MM MM

916.5FSP

14

人月个月

软件项目成本估算轮廓工作量（MM） 小型 2KDSI 中小型 8KDSI 中型 32KDSI 大型 128KDSI 超大型 512KD

SI组织型 5.0 21.3 91 392

半独立型 6.5 31 146 687 3250

嵌入型 8.3 44 230 1216 6420

生产率 (DSI/MM) 小型 2KDSI 中小型 8KDSI 中型 32KDSI 大型 128KDSI 超大型 512KD

SI组织型 400 376 352 327

半独立型 308 258 219 186 158

嵌入型 241 182 139 105 80

进度（月） 小型 2KDSI 中小型 8KDSI 中型 32KDSI 大型 128KDSI 超大型 512KDSI

组织型 4.6 8 14 24

半独立型 4.8 8.3 14 24 42

嵌入型 4.9 8.4 14 24 41

平均人员（ FSP） 小型 2KDSI 中小型 8KDSI 中型 32KDSI 大型 128KDSI 超大型 512KD

SI组织型 1.1 2.7 6.5 16

半独立型 1.4 3.7 10 29 77

嵌入型 1.7 5.2 16 51 157

工作量在软件开发各阶段的分布工作量分布 规模

开发模式 阶段 小型2KDSI

中小型8KDSI

中型32KDSI

大型128KDSI

超大型512KDSI

组织型 计划与需求（%） 6 6 6 6

产品设计 16 16 16 16

编程 68 65 62 59

详细设计 26 25 24 23

编码与单元测试 42 40 38 36

集成与测试 16 19 22 25

进度分布

进度分布 2KDSI 8KDSI32KD

SI128K

DSI512K

DSI

组织型 计划与需求 10 11 12 13

产品设计 19 19 19 19

编程 63 59 55 51

集成与测试 18 22 26 30

半独立型 计划与需求 16 18 20 22 24

产品设计 24 25 26 27 28

编程 56 52 48 44 40

集成与测试 20 23 26 29 32

嵌入型 计划与需求 24 28 32 36 40

产品设计 30 32 34 36 40

编程 48 44 40 36 32

集成与测试 22 24 26 28 30

三种模式下一个中型项目的绝对工作量

模式 开发工作量（MM）

编码与单元测试所占百分比（%）

编码与单元测试工作量（MM）

组织型 91 38 35

半独立型 146 33 48

嵌入型 230 28 64

进度估算举例仍然用 320KLOC 的中型项目为例我们从前面

的 COCOMO 估算已近确定该项目需要 91 个人月的工作量和 14 个月的进度。假设我们需要该项目在编码阶段的时间量、工作量和相当于全职的软件人员平均数的估算，根据表的工作量部分，编码阶段需要总工作量的 62% ，即

0.62 * 91 人月 = 56 人月根据进度分布表，编码阶段需要总进度的 55% ，即：

0.55 * 14 个月 = 7.7 个月编码阶段所需要的人员数的平均数是：

56 人月 / 7.7 个月 = 7.3 FSP

4.4.3.2 中等 COCOMO

采用对应于 15 个成本驱动因子的属性系数进行调整。

中等 COCOMO 的基本估算公式（与基本 COCOM 不同）：

开发模式 标称工作量公式

组织型 (MM)NOM=3.2(KDSI)1.05

半独立型 (MM)NOM=3.0(KDSI)1.12

嵌入型 (MM)NOM=2.8(KDSI)1.20

调整因子：产品属性 （ 1 ）产品属性：与产品本身或者与需要完成的

任务本质相关的，迫使项目成本上升或者下降的一些属性。 RELY （ Required software reliability ，软件可靠性）

——主要应用于实时系统； DATA （ Data base size ，数据库规模）——主要应

用于数据处理系统； CPLX （ Product complexity ，软件产品复杂性）——

执行时间的限制。

调整因子：计算机属性 （ 2 ）计算机属性：与作为支持工具的计算机平

台有关，而且与要完成的任务有关的其它属性： TIME （ Execution time constraint ，执行时间约束）

——主要应用于当处理器速度勉强满足要求时； STOR （ Main store constrain ，主存储器约束）——

主要应用于当存储器大小勉强满足要求时； VIRT （ Virtual machine volatility ，虚拟机的易变性）

——包括目标设备的硬件和操作系统； TURN （ Computer turnaround time, 计算机周转时

间）——用于开发（当前考虑的比较少）。

调整因子——人员属性 （ 3 ）人员属性：与完成工作的人员相关的属性，

这些成本驱动因子可能会极大的增加或者减低成本： ACAP （ Analyst Capability ，分析员能力）； AEXP （ Analyst Experience ，分析员经验）； PCAP （ Programmer Capability ，程序员能力）； VEXP （ Virtual Machine Experience ，虚拟机经验）

——包括操作系统和硬件； LEXP （ Language Experience ，编程语言经验）—

—包括工具和方法。

调整因子——项目属性 （ 4 ）项目属性：与方法和工具有关的属性：

MODP （ Modern Programming practices ，现代编程规范）结构化技术或者面向对象技术；

TOOL （ Use of software tools ，软件工具的使用）—— CASE ，优秀的调试工具、测试、生成工具等；

SCED （ Required development schedule ，所需的开发进度）——与设想的进度是否有偏差，如果进度提前的话是比较糟糕的。

因子取值：成本驱动因子

等级

很低 低 标称 高 很高 极高

产品属性

RELY 0.75 0.88 1.00 1.15 1.40

DATA 0.94 1.00 1.08 1.16

CPLX 0.70 0.85 1.00 1.15 1.30 1.65

计算机属性

TIME 1.00 1.11 1.30 1.66

STOR 1.00 1.06 1.21 1.56

VIRT 0.87 1.00 1.15 1.30

TURN 0.87 1.00 1.07 1.15

人员属性

ACAP 1.46 1.19 1.00 0.86 0.71

AEXP 1.29 1.13 1.00 0.91 0.82

PCAP 1.42 1.17 1.00 0.86 0.70

VEXP 1.21 1.10 1.00 0.90

LEXP 1.14 1.07 1.00 0.95

项目属性

MODP 1.24 1.10 1.00 0.91 0.82

TOOL 1.24 1.10 1.00 0.91 0.83

SCED 1.23 1.08 1.00 1.04 1.10

中等 COCOMO 举例我们来举个例子，假如有一组 32 KLOC 的、

半独立型模式软件产品的开发，中级 COCOMO 模型的标称工作量是 3.0 （ 32 ） 1.12=146 人月。此时产品的 15 个成本驱动因子的标称值都为 1 。然后我们考虑产品有如下特征时的工作量修正： （ 1 ）若该产品是一个实验系统、或者可行性演示系统，软件错误影响的只是不便于开发人员修正错误（因为还没有提交给用户使用），可以具有很低的可靠性（表 2 ）那么该产品需要的工作量是：

（ 146 人月） * （ 0.75 ） = 110 人月

（ 2 ）若该产品是一个长期计划的模型（如气象预报模型），运行需要很长的时间，可靠性相对低。大部分的错误只是给用户带来比较低的、易于恢复的损失。此时该产品修正后的工作量估算是： （ 146 人月） * （ 0.88 ） = 128 人月

（ 3 ）若该产品是信息管理系统，需要标称可靠性的软件。而且这类系统如果出现错误，那么这些错误影响是比较大的，但不需要太大的代价就可以修复。那么该产品需要的工作量依然是： （ 146 人月） * （ 1.00 ） = 146 人月

（ 4 ）若该系统是一个银行交易系统或者电力分配系统，要求该系统高可靠性。若出现错误，那么错误的影响将是大量的财务损失，此时调整后的工作量是： （ 146 人月） * （ 1.15 ） = 168 人月

（ 5 ）若该系统是军事指挥控制系统或者核反应堆控制系统等，要求很高的可靠性，软件错误很可能会影响到人员的伤亡。为了获取很高的可靠性，修正后的工作量是： （ 146 人月） * （ 1.40 ） = 204 人月

举例总结

从以上 5 种情况我们可以发现，产品所需要的可靠性越高所需要的工作量就越大。这是由于软件的开发分为四个主要的步骤，所需的可靠性在这四个步骤所需要做的工作以及这些工作的质量就越高，从而导致整个开发工作量的增加。

4.5 软件项目团队 软件项目团队的组建是项目启动阶段的主

要工作之一，可以参考 COCOMO 所估算的 FSP 来预估项目团队的人数。

所需要注意的内容有： 4.5.1 项目团队组织 4.5.2 项目经理选择

4.5.1 项目团队组织

Joe SamplebossCEO

Jane Samplemgr开发部经理

系统测试员

系统实施人员

程序开发员

质量风险评估委员会

系统分析员

文档管理员

业务分析员

系统管理员

4.5.2 项目经理 项目经理职责：

编制计划确定组织知道工作监督和管理

项目经理权力团队组建权资金管理和控制权 项目实施权 项目内部资源调度权 项目宏观调控和微观决策权

项目经理的素质和要求：良好的道德素质健康的身体项目管理的理论和实际经验项目所属领域的知识系统的思维能力（哲学）娴熟的管理能力积极的创新能力丰富的软件项目管理经验勤奋努力

4.5.3 团队管理与人力资源计划 人力资源的配备原则如下：

开发人月少而精；梯队特点：技术水平的高、中、低分布比例最好为 1 ： 2 ： 4 ；

按软件项目的各个阶段的要求动态的组建成员，不需要一下子招齐。

团队管里重点： 制定与项目相关的规章制度建立明确的共同目标（猎狗与兔子的故事）

营造积极进取的团结气氛良好的沟通机制及时发现并解决团队管里重的问题做好团队的稳定工作。

待续。。。