北京理工大学
软件工程实践
汤铭端
中国航天科工集团公司 706所
第八讲
软件估计
软件项目跟踪与控制
内容和目的
? 了解软件估计的概念
? 掌握基本的软件估计方法
? 掌握软件项目追踪与控制的原理
? 了解软件项目追踪与控制的过程
软件估计
软件工作量估算
有些估算做得很仔细，而有些却只是
凭直觉的猜测。大多数项目超过估算进
度的 25%到 100％，但也有少数一些组织
的进度估算精确到了 10％以内，能控制
在 5％以内的还没有听说。
—— Jones,1994
软件工作量估算
,大多数 IS人士，无论是否为管理者，从来都无
权控制他们自己的进度计划。进度计划通常由
市场部或高层管理部门直接下达，就像飞石从
天而降（也有人称之为鸟粪）,
,就此问题，我曾与 IS领域中许多人士进行过交
流。大家一致认为当前 IS领域面临的最大难题，
既不是掌握快速更新的技术，也不是探求新型
的管理哲学，而是被迫接受根本无法达到的进
度计划。, （ Robert.L.Glass)
一个月的时间
造这样一栋房
子？没问题
太好了，那我
们开工吧！
你当初计划 10万元造的房屋可能最终的实际造价为 50万元。
从造房子中学到的
? 除非你确切知道, 它, 是什么？否则无
法说明它的确切花费。
? 盖房子时，可以盖梦想中的房子（不考
虑花费），也可以按估算盖，但是功能
必须具有一定的灵活性
软件工作量估算困难的原因
? 估算困难是由于软件的本质带来的，特别是其复杂性
和不可见性。
? 软件开发是人力密集型工作的，因而不能以机械的观
点来看待
? 传统的工程项目经常会议相近的项目做参考，不同的
只是客户和地点，而绝大部分软件项目是独一无二的。
? 新技术的不断出现和应用。
? 缺少项目经验数据，许多组织无法提供原有项目数据，
而即使提供了这些项目数据，也未必非常有用。
工作量估算的其它困难
? 某些人试图建立一个过去项目的全软件业的数
据库，但是许多词汇意义的不明确使得这种努
力没有效果，例如, 测试, 阶段究竟包括哪些
活动就不明确。
? 估计的主观性,人们容易低估小项目的工作量，
而过分夸大大项目的工作量
? 估计的政治因素,不同的人有不同的目标，如
项目经理会高估项目工作量，许多机构采用独
立的估算小组，但是将项目经理和项目成员吸
收进估算小组，能够增强他们的责任感。
何时需要估算
? 策略计划：选择合适的项目
? 可行性分析
? 系统描述：实现各个需求的工作量需要被衡量
? 评估供应商的建议
? 项目计划,
? 项目进行过程中，估算越来越准确
? 在项目开始阶段考虑的是用户需求，不考虑实现，
但是为了估算，有时需要考虑一些实现方法
过高估计和过低估计的问题
? 过高估计的问题
? Parkinson法则：给的时间越多，工作花费的时间也越多
? Brook法则：当人数增加后，项目所需的工作量 将不成比例
的增加。当团队规模变大后，由于管理，协调和通信的增加，
将造成工作量的增加。因而, 投入更多的人将使延期的工作
更加延期,
? 过低估计的问题
? 质量降低
? Weinberg的可靠性零法则, 如果系统不必可靠，那么它可以
满足任何目标, 。
工作量估算对职员的影响
? 如果职员能够完成目标，那么他们将受
到鼓舞
? 如果他们发现目标根本不能完成，那么
他们的激情将受到极大损害
? 因而，估计不是一种简单的预测行为，
而是一种管理目标
软件估算的基础
? 历史数据的需要
? 在参考历史数据时需要考虑不同的环境，如编程语言，
软件工具，标准和人员的经验。
? 工作度量
? 直接计算真正的成本或时间是不可能的。编写程序的时
间不同的人将有显著的区别。
? 通常将工作量表达为如源代码的数量（ source line of
code,SLOC）,或者千行代码量（ KLOC）
? 复杂性
? 相同 KLOC的两个程序花费的时间将会不同。因而不能简
单地应用 KLOC或 SLOC,而要根据复杂性进行修正，但是
复杂性的度量通常是主观而定的。
基于承诺的估计（后墙不倒）
? 一些组织直接从需求出发安排进度而不进行中
间的工作量估算。他们要求每个开发者作出进
度承诺而非进度估算。
? 有利于开发者对进度的关注，开发者在接受承
诺后士气高昂，自愿加班加点
? 问题在于开发者的估算比现实要乐观，大约低
20至 30个百分点（ Van Genuchten,1991)
? 承诺应该现实可行，以使你的团队会不断成功
而不是不断失败。
软件项目估计的对象内容
? 对象
? 项目
? 活动
? 工作包
? 内容
? 规模
? 工作量
? 持续时间（工期）
? 资源需求量
? 成本
估计量之间的关系
? 整体 =局部之和
? 工作量主要由规模确定
? 工作量 =资源数目 х工期
? 成本 =人力成本 +材料成本 +设备成本
? 人力成本 =工作量 х单位价格
软件估计方法
? 通用方法
? 1 类比方法
? 2 经验方法
? 3 模型方法
? 4 分解法
? 5 三点法
? 6 Delphi技术
? 规模、工作量、工期、
成本估计方法
? 7 自上而下
? 8 自下而上
? 9 生产率因子方法
? 10 功能点方法
? 11 COCOMO方法
? 12 IBM模型
1 类比方法
? 类比方法又被称为基于案例的推理（ Case-
based reasoning）
? 使用过去类似项目的确切数字，考虑与当前项目的差
异程度，来估计当前项目的相应数据。
当前项目估计 =参考项目数据×（ 1+差异百分比）
? 差异百分比当前项目比参考项目多（正）或少（负）
的百分比。
? 规模估计可以选取功能、输入输出等作为比较的参考
依据。
类比法示例
? 如当前项目系统与系统 XYZ类似
? XYZ系统的规模是 10K代码行
? 当前系统比 XYZ系统增加了约 10%的功能
? 对当前系统的规模估计是,
10K×（ 1+10%） =11K
2 经验方法（专家判断）
? 根据估计者自己的经验进行估计
? 具有应用领域知识的人员对任务的评估
? 该方法特别是在对原有系统进行替换时有用，评估
者对影响的代码的比例进行分析，从而得到工作量
评估
? 根据大家的共同经验进行估计
? 标准工法
? 标准工时
? 根据项目和项目组的具体情况进行调整
各阶段工作量分布
阶段
工作量分布比例
需求分析
18%
项目策划
5%
设计
20%
实现和集成
32%
测试
24%
形成产品
1%
3 模型方法（参数估算法）
? 是一种使用项目特性参数建立数据模型来估算的方法，
是一种统计技术，如回归分析和学习曲线。
? 模型可以简单也可以复杂
? 参考历史信息
? 重要参数必须量化处理
? 根据实际情况，对参数模型按适当比例调整
? 应该具有良好的数据库数据为基础
? 比较简单,而且也比较准确
? 是最常用的估算方法
? 如果模型选择不当或者数据不准,也会导致偏差
4 分解方法
? 进行整体估计感觉困难的时候，可以采用分解方法。
? 软件的功能结构、物理结构、软件项目的 WBS等都为分
解估计方法提供了参考框架。
? 如根据软件的功能结构（逻辑结构）和 /或软件（可能）
的物理结构，将软件进行逐步分解，直至分解到能够
对最小块进行较准确的估计。
? 分别采用基于经验的方法和 /或某种估计方法，对分解
得到的各块进行估计。
? 将这些子块的估计加在一起，获得对项目软件的整体
估计。
5 三点法（ Putnam模型）
? 假设估计是概率事件，服从 ?分布
? 通过估计
? 悲观（最大）值
? 最可能值
? 乐观（最小）值
? 加权平均的估计方法
估计期望值 =
（最大值 +4×最可能值 +最小值） /6
工作时间的分布与计算
三点法示例
? 若你认为软件规模,
? 最大值是 100K代码行
? 最小值是 50K代行
? 最可能值是 60K代码行
? 则加权平均所获得的规模估计初始期望
值为,
（ 50+4× 60+100） /6=65K代码行
6 德尔菲 (Delphi)方法
? 在难以获得经验、历史数据及专家时，可考虑采用德尔菲
方法作为一种有效的替代估计方法。
? 德尔菲方法通过群体的智慧和交流分析来获得不断趋向准
确和一致的估计结果。
? 过程：成立估计小组，首先介绍项目和产品情况，而后让
估计小组成员分别进行估计，结果（第一轮）以列表和
（或）直方图形式反馈给小组成员。在此基础上，估计值
比平均值相差大的人各自讲述自己的理由，然后再分别进
行下一次估计，得到新的估计结果（第二轮）。再次让小
组讨论后进行新的估计（第三轮）。在第三轮结果的基础
上进行最后的调整，得到的平均值就是估计结果。
? 通过上述估计和反馈过程，人们的估计会越来越接近，意
见更为统一，也就能得到综合各方面意见更为准确的结果。
宽带德尔菲 (Wide Band Delphi)
? 选择 3至 10名具有管理和估计经验的人员作为估计员
? 共同讨论和了解软件项目的目标、范围、需求、资源
? 分别按照各自的方法，对软件规模进行估计，并记录
? 分别分析项目估计的意外与风险，并确定估计风险与意外
调整百分比
? 分别根据其初始估计和估计风险与意外调整百分比，确定
各自的最后估计或最后估计范围。计算公式为,
? 最后估计 =初始估计×（ 1+意外调整百分比）
? 最后估计范围 =（ 1+[减少调整百分比，增加调整百分比 ]）
×初始估计
? 必要时，安排进行讨论和再评估，以便进一步取得一致
? 估计负责人对所有的最后估计进行平均，获得规模估计
7 从下向上方法
? 这种技术通常首先估计各个 独立工作,
然后再汇总从下往上估计整个项目
? 首先将项目分成部件任务，然后估算每
个任务
? 在大型的项目中，分解任务的过程是一
个叠代的过程，直到最下面的任务不可
分解，产生 WBS
从下向上估计法图示
工作包
从下向上估计法,
·估计工期
·估计资源
·估计费用
·估计工作量
8 从上往下 方法
? 同 从下向上 相反
? 从上往下逐步估计的
? 多在有 类似项目已 完成 的情况下应用
从上往上估计法图示
从上向下估计法,
·工作范围
·进度目标
·费用目标
9 生产率因子方法
? 假设在同等条件下开发速度（生产率）是一个常数。
? 各机构可以根据以前的工作经验和历史数据，获得生
产率因子。再根据估计的软件产品规模，估计项目的
工作量和持续时间。
? 确定项目产品的功能点
? 估计项目工作量和持续时间
5 功能点 /人月 ≤ 生产率因子 ≤9 功能点 /人月
生产率因子平均值 =8 功能点 /人月
工作量（人月） =功能点数 /生产率因子
持续月数 = 2.5×（工作量人月数） 0.38
? 各阶段工作量划分
10 功能点方法
? 代码行数与编程语言相关的，不具可比性
? 功能度量是一致的、可比的
? Albrecht功能点分析是由 Allan Albrecht在 IBM工作时
发明的自顶向下方法。
? 功能点法（ Function Points） 的基本点是计算机信息
系统包括五个主要部件或者外部用户类型，它们是,
? 外部输入：应用数据
? 外部输出：提供给用户的面向应用的信息
? 内部逻辑文件：逻辑主文件
? 外部接口文件：与其它系统交换信息
? 外部查询：在线的输入以获得立即的结果
功能点的计算
? 先进行核心计算获得未调整功能点（ UFP）,然后
用调整因子获得值调整因子（ VAF）,将 UFP乘以
VAF,就达到了调整功能点（ AFP）。
AFP=UFP× VAF
? UFP的计算：考虑五个功能分量：外部输入 EI,外
部输出 EO,外部查询 EQ,文件 EIF,外部接口 ILF。
UFP= IEI× EI+ IEO× EO+ IEQ× EQ+ IEIF× EIF+
ILIF× LIF
? VAF根据软件项目和软件产品的 14个相关属性计算
获得 。
未调整功能点 UFP计算公式
测量参数 计数 简单 平均 复杂
用户输入数
×
3 4 6 =
用户输出数
×
4 5 7 =
用户查询数
×
3 4 6 =
文件数
×
7 10 15 =
外部接口数
×
5 7 10 =
总计数值
×
=
五个功能分量
? 用户输入数,计算每个用户输入，它们向软件提供面向应用的数
据。输入应该与查询区分开来，分别计算。
? 用户输出数,计算每个用户输出，它们向用户提供面向应用的数
据。这里输出是指报表、屏幕、出错信息等。一个报表中的单个
数据项不单独计算。
? 用户查询数,一个查询被定义为一次联机输入，它导致软件以联
机输出的方式产生实时的响应。每一个不同的查询都要计算。
? 文件数,计算每个逻辑的主文件（如数据的一个逻辑组合。它可
能是某个大型数据库的一部分或一个独立的文件。）
? 外部接口数,计算所有机器可读的接口（如磁带或磁盘上的数据
文件），利用这些接口可以将信息从一个系统传送到另一个系统。
调整功能点 AFP计算公式
? AFP=UFP× [0.65+0.01× ∑Fi],I=1-14
? Fi是对影响产品规模的 14个因素进行分析确定
的, 复杂度调整值,,取值范围是 0-5
? Fi通过回答后面的问题后参照以下标尺得到
0 1 2 3 4 5
没有
影响
偶有
影响
轻微
影响
平均
影响
较大
影响
严重
影响
Fi
1,系统需要可靠的备份和复原吗？
2,需要数据通信吗？
3,有分布处理功能吗？
4,性能关键吗？
5,系统是否在一个已有的、很实用的操作环境中运行？
6,系统需要联机数据项吗？
7,联机数据项是否需要在多屏幕或多操作之间切换以完成输入？
8,需要联机更新主文件吗？
9,输入、输出、文件或查询很复杂吗？
10,内容处理复杂吗？
11,代码需要被设计成可重用吗？
12,设计中需要包括转换及安装吗？
13,系统的设计支持不同组织的多次安装吗？
14,应用的设计方便用户修改和使用吗？
功能点转换为代码行
? 通过定义各个功能点对应各种语言的代
码行数，则功能点可以转化为代码行
? 一些数据,
? Cobol,91
? C,128
? Quick Basic,64
? Object Oriented Languages,30
功能点和各种语言代码行对比
程序设计语言 LOC/FP 程序设计语言 LOC/FP
汇编语言 320 面向对象语言 30
C 128 第四代语言 20
COBOL 105 代码生成器 15
FORTRAN 105 电子表格 6
PASCAL 90 图形语言 4
ADA 70
功能点的扩充
? MarkII功能点
? 功能点 =-0.58× 输入数据元素＋ 1.66× 实体＋
0.26× 输出数据元素
? 特征点（ Feature Points):除了考虑普通功能点的内
容外，还考虑了算法的特征（矩阵转换，字符串解析，
处理中断等都是算法的例子）
? Boeing提出了一个三维功能点方法（ 3D） 其中三维为
数据维，功能维（输入转化为输出的步骤）和控制维
（状态之间的转换数）
? 对象点：计算需要处理的屏幕，报告和部件等（称为
对象）
11 COCOMO方法
? 构造性成本模型（ COnstructive COst MOdel）
? Barry Boehm 在二十世纪 70年代采用他的模型对 63个
项目进行了研究，由于其中只有 7个是商务系统，因而
它们不仅仅能被用于信息系统
? 当前使用最为广泛和最有效的估计软件项目开发成本
和工作量的方法
? 两个核心方程：用规模估计工作量；用工作量估计项
目持续时间
Effort = a× ( Size ) b
Tdev = c× ( Effort ) d
? Effort(人月 ),Size(KLOC),Tdev(月 )
COCOMO的层次
? 基本 COCOMO模型：将软件开发工作量（或成
本）作为程序规模的函数进行计算，程序规模
以估算的代码行表示
? 中级 COCOMO模型：将软件开发工作量（或成
本）作为程序规模及一组, 成本驱动因子, 的
函数来进行计算，其中, 成本驱动因子, 包括
对产品、硬件、人员、项目属性的主观评估
? 高级 COCOMO模型：包含了中级模型的所有特
征，并结合了, 成本驱动因子, 对软件工程过
程中每一个步骤（分析、设计等）的影响的评
估
COCOMO针对的软件项目类型
? 有机方式（ Organic）,主要关注数据处理、事务和数
据检索
? 较小的、简单的软件项目，有良好应用经验的小型
项目组，针对一组不是很严肃的需求开展工作
? 嵌入式方式（ Embedded）,基于硬件系统的集成部件
? 必须在一组严格的硬件、软件及操作约束下开发的
软件项目
? 半分离方式（ Semi-Detached）,介于有机方式和嵌入
式方式之间
? 一个中等的软件项目，具有不同经验水平的项目组
必须满足严格的及不严格的需求
基本 COCOMO的参数
a b c d
有机 2.4 1.05 2.5 0.38
半分离 3.0 1.12 2.5 0.35
嵌入 3.6 1.20 2.5 0.32
中级 COCOMO的公式和参数
a b
有机 2.8 1.05
半分离 3.0 1.12
嵌入 3.2 1.20
Effort = a× ( Size ) b× EAF
EAF= ΠＦ Ｉ (I=1-15)
? 产品属性
? RELY,所需的软件可靠性
? DATA,数据库的大小
? CPLX,产品复杂性
? 计算机属性
? TIME,执行时间方面的约束
? STOR,主存限制
? VIRT,虚拟机的易变性
? TURN,计算机周转时间
? 人员属性
? ACAP,分析员能力
? AEXP,应用领域中的实际经验
? PCAP,程序员能力
? VEXP,虚拟机使用经验
? LEXP,程序语言使用经验
? 项目属性
? MODP,现代程序设计方法
? TOOL,软件工具的使用
? SCED,所需的开发进度
ΠＦ Ｉ 表示 15个成本属性的取值连乘，从产品、计算机、人
员、项目等方面考虑
每个成本属性取值在 0.9至 1.4。平均情况下取 1.0；如果
对成本的影响较大取大于 1.0；否则取小于 1.0
高级模型
? 高级模型进一步对中级模型进行了两方
面的改进,
a,提出了针对不同开发阶段的成本属性因子
b,提出了成本属性因子按照模块级、子系统
级、系统级等三级产品层次结构变化和确定
COCOMO2.0
? 1995年形成适用面更宽、更为精确的改进模型 COCOMO2.0
? COCOMO2.0的核心公式与 COCOMO一致，但系数不同
? a取常参数 2.5,b变参数，由五个属性共同确定,
? PERC,开发先例
? FLEX,开发灵活性
? RESL,体系结构 /风险解决方案
? TEAM,小组凝聚力
? PMAT,过程成熟度
? 分别在 1.0周围取值 W1,W2,W3,W4,W5
? b = 1.01 + 0.01 ∑ Wi
12 IBM模型
? 总结 IBM的 60个项目数据，其中源代码从 400到
467000，开发工作量从 12人月到 11578人月，
使用了 29种编程语言和 66中不同的计算机。
E = 5.2 × L 0.91
D = 4.1 × L 0.36 = 2.47 × E 0.36
S = 0.54 × E 0.6
DOC = 49 × L 1.01
? 其中,E为开发工作量，单位为人月； D为项目
持续时间，单位为月； DOC为文档页数； L为源
代码行数； S为所需的开发人员数。
估算的技巧
? 避免无准备的估算
? 不要随口说出一个估算
? 留出估算的时间，并做好计划
? 估算本身也是一个项目
? 开发人员参与估算
? 不要忽略普通任务
? 使用几种不同的估算技术，并比较它们的结果
? 估算的群体讨论
过于乐观的进度计划
? Microsoft Word for Windows 1.0开发
? 包含 249,000行代码，投入 660人月，前后历时 5年，
实际花费时间为预期时间的 5倍
过于乐观的进度计划
? 导致 WinWord1.0开发延迟的几个主要因素,
? 项目初期制定的开发目标是不可实现的。盖茨下达的指示是
用最快的速度开发最好的字处理软件，争取在 12月内完成。
实现这两个目标中的任何一个都是困难的，同时达到则是不
可能的。
? 过紧的进度计划降低了计划的精确度。
? 开发过程中频繁换人。 5年中共换了 4个组长，其中有 2人因进
度压力离职,1人是出于健康的原因而离职。
? 迫于进度压力，开发人员匆忙写出一些低质量的和不完整的
代码，然后宣称已实现某些性能。这造成了 WinWord不得不将
用于提高软件稳定性的时间由预计的 3个月增加到 12个月。
? 由于该项目中，创新比速度更重要，因而试图缩短开发周期，反
而使周期变长
产生过于乐观的进度计划的根源
? 为了赶在某些特定时间前展示或出售产品。如计算机
交易展示会。
? 管理人员和客户拒绝接受仅给出范围的估算，而是按
照他们认为的, 最佳, 估算来制定进度计划。
? 项目管理人员和开发人员为了享受挑战的乐趣或在压
力下工作的刺激，而故意缩短进度计划。
? 管理部门和市场部门为了迎合客户而缩短进度计划。
? 项目管理人员认为较紧的进度计划能够使员工勤奋工
作。
? 原先的估计是合理的，但是在项目进行过程中又加进
了很多新特性，从而变成了过于乐观的进度。
? ……
过于乐观的进度计划的后果
? 进度计划准确性
进度完成日期
按期完成概率 开发人员一般
采用的较乐观
的进度计划
典型的过
分乐观的
进度计划
过于乐观的进度计划的后果
? 计划的质量：错误的假设必将导致无效的项目
规划。
? 抛弃计划：当面临进度压力时，大多数开发组
织会抛弃原有规划，而走入盲目开发的歧途。
? 如果试图在关键阶段节省时间，必将在后续阶
段加倍补偿。
? 分散了管理者的注意力：管理者将分散经历在
不断调整计划上。
? 客户关系：项目一拖再拖，客户将失去耐心。
过于乐观的进度计划的后果
? 仓卒收尾
? 要排错只能将系统拆分后再进行，一个小的变动要
花很长时间。
? 开发人员清楚地知道系统中存在一些应作修改却未
做的地方。
? 测试人员发现错误的速度大于开发人员排错的速度。
? 排除已发现错误的同时，产生了大量新的错误。
? 由于软件变化频繁，难以保证用户文档的同步更新。
? 项目估算多次调整，软件交付日期一拖再拖。
超负荷的进度压力
? 产品质量的降低
? 赌博心理导致风险管理的忽略
? 激励效应不再起作用
? 创造性思维受损
? 精疲力竭：在后面的项目中难以提起热情
? 中途退出：这些人通常是有能力的人
? 长期地进行快速开发：难以补充新知识
? 开发人员与管理人员的关系：不切实际的进度
压力会使开发人员丧失对管理人员的尊重 。
估算不准的原因
? 缺乏经验的估算人员
? 过分乐观
? 考虑不周
? 方法不一致
? 签约前后不连贯
? 低劣的推测技术
对付估算误差
? 避免低劣估算
? 处理低劣估算带来的后果
避免低劣估算
? 尽可能使企业的估算机构专业化
? 避免估算缺陷
? 过分乐观
? 政治压力
? 低劣估算模型
处理低劣估算带来的后果
? 通过数据说明资源不足,争取更多资源
? 强化变更管理程序
? 确定目标的优先次序
项目的追踪和控制
项目管理
? 制定计划
? 按计划去做
? 执行计划
? 检查计划的执行情况
? 控制对计划的偏差
对比
? 项目管理
? 计划
? 执行
? 追踪
? 控制
? PDCA环
? 计划
? 执行
? 检查
? 处理
项目的追踪和控制
? 计划、追踪、控制是项目管理不可分割
的三个环节
? 控制的基础是信息，信息的获得靠追踪
? 计划 -追踪 -控制是一个封闭循环，一个系
统过程，一个以信息为共同核心的相互
依赖、相互制约的互动过程。
? 计划 -追踪 -控制的主要对象是进度、成本、
质量
项目跟踪控制的定义
? 项目跟踪和控制是管理项目实施的两个
不同性质但却密切相关的活动
? 项目跟踪是项目控制的前提和条件
? 项目控制是项目跟踪的目的和服务对象
项目跟踪
? 在项目实施的全过程对项目进展的有关
情况以及影响项目实施的内外因素进行
及时的、连续的、系统的、准确的记录
和报告的一系列活动和过程。
? 目的是为项目管理者提供项目计划执行
情况的相关信息
项目控制
? 项目控制过程是为了保证项目成功和各
项目标的实现，对项目执行过程中出现
偏差采取必要的、有针对性的措施加以
纠正的过程。
? 项目控制是一个动态的过程，在不断获
取项目跟踪所得信息的基础上，要对所
发生的问题及时采取解决
项目跟踪控制的关系
跟踪系统 控制系统
信息
决策和命令
项目追踪和监督 — CMM的要求
活动 1 将已文档化的软件开发计划用于跟踪软件活动和
传送状态。
活动 2 按照已文档化的规程修订项目的软件开发计划。
活动 3 高级管理者参与按照已文档化的规程评审那些对
组织外部的个人和组所作的软件项目约定和约定的更
改。
活动 4 将经批准的、影响软件项目约定的更改传达给软
件工程组和其它软件－有关组的成员。
活动 5 跟踪软件工作产品的规模（或者软件工作产品更
改的规模），必要时采取纠正措施。
活动 6 跟踪项目的软件工作量和成本，必要时采取纠正
措施。
项目追踪和监督 — CMM的要求
活动 7 跟踪项目的关键计算机资源，必要时采取纠正措
施。
活动 8 跟踪项目的软件进度，必要时采取纠正措施。
活动 9 跟踪软件工程技术活动，必要时采取纠正措施。
活动 10 跟踪与项目的成本、资源、进度及技术方面有关
的软件风险。
活动 11 记录软件项目的实际测量数据和重新策划的数据。
活动 12 软件工程组进行定期的内部评审以便对照软件开
发计划跟踪技术进展、计划、性能和问题。
活动 13 按照已文档化的规程在所选择的项目里程碑处进
行正式评审以评价软件项目的完成情况和结果。
软件项目的追踪与控制
? 追踪
? 了解项目的进展情况
? 采集项目进展数据
? 统计分析
? 与计划对比
? 发现与计划的偏差
? 控制
? 分析偏差
? 决策是否调整计划
? 按规程调整计划
? 评审、实施、管理
跟踪内容
? 监督执行情况
? 测量和预测发展情况
项目跟踪系统
收集、输入 加工、处理、存储 报告、输出
信息
信息
项目追踪系统的设计 …
? 项目追踪对象
? 范围
? 变更
? 关键假设
? 资源供给
? 非项目时间
? 主要里程碑
? 进度
? 工作时间及任务完成情况
? 项目总结报告
? 收集信息范围
? 投入活动信息
? 采购活动信息
? 实施活动信息
? 项目产出信息
项目追踪系统的设计
? 项目追踪过程
? 观察
? 测量
? 分析
? 报告
项目追踪的方式
? 定期会议报告
? 项目组成员定期报告
? 里程碑检查
? 评审记录审查
? 软件质量保证人员报告
? 统计分析
? 与计划对比
软件项目追踪与控制过程
? 确定追踪元素
? 工作量、成本、进度、资源、风险
? 追踪
? 个人工作周记
? 项目工作月报
? 阶段总结报告
? 分析决策
? 计划
工作产品名称
规模
工作量
成本
开始日期
完成日期
计
划
实
际
计
划
实
际
计
划
实
际
计
划
实
际
计
划
实
际
规模、工作量、成本和进度跟踪表
序
号
名称
型号版本
数量
技术指标
使用起始日期
使用持续日期
备注
计
划
实
际
计
划
实
际
计划
实际
计
划
实
际
计
划
实
际
关键资源跟踪表
序
号
名称
型号版本
数量
技术指标
使用起始日期
使用持续日期
备注
计
划
实
际
计
划
实
际
计划
实际
计
划
实
际
计
划
实
际
风险跟踪表
课题名称
时段
填表人
岗位
填表日期
工作产品名称
完成比例
规模
投入时间
总体
新编
更新
总计
周 1
周 2
周
3
周
4
周 5
周 6
周日
工作陈述,
下周工作计划,
上级主管评语,
附注,
个人工作周报
进展度量准则
?完成百分比法
? 里程碑法 （ 0对 100法 ）
? 20对 80法
? 50对 50法
完成百分比法
? 已经完成的分活动和总的活动预算的百
分数
? 只有当你精确知道已经完成任务的百分
比时才能用该方法
? 该方法较为精确
里程碑法（ 0对 100法）
? 活动完成前一直是零
? 活动完成后为 100%
? 保守
20对 80法
? 活动开始前为的 0
? 开始后为 20%
? 完成后为 100%
50对 50法
? 活动开始前为 0
? 开始后为 50%
? 完成后为 100%
文档编制完成百分比计算方法
事件
工作完成百分比
启动
10
启动内部评审
50
完成内部评审
75
文档通过正式评审, 并已受到软件配置管理
100
短期工作完成百分比计算方法
事件
工作完成百分比
任务启动
50
任务完成
100
需求分析完成百分比计算方法
事件
工作完成百分比
任务启动
10
完成系统级需求和相关算法的定义
40
需求分类并详细说明
55
完成软件需求规格说明到系统规格说明的追踪
65
启动内部评审
75
完成内部评审
90
文档通过正式评审, 并已受到软件配置管理
100
设计工作完成百分比计算方法
事件
工作完成百分比
启动任务
10
完善数据流图, 定义相关算法
25
定义软件单元和结构关系
35
定义了每个软件单元的所有性能规格说明 /算法
50
定义了每个软件单元的接口规格说明
60
完成软件设计文档到软件需求规格说明的追踪
70
启动内部评审
80
完成内部评审
90
文档通过正式评审, 并已受到软件配置管理
100
程序开发完成百分比计算方法
事件
工作完成百分比
启动任务
10
完成编码
50
完成代码审查
60
完成代码单元测试
85
软件单元追踪到软件设计文档
95
代码存入软件配置管理库
100
测试设计完成百分比计算方法
事件
工作完成百分比
启动任务
10
确定测试用例设计原则
30
设计完测试用例
60
形成测试说明
75
启动内部评审
80
完成内部评审
90
测试说明存入软件配置管理库
100
课题名称
月 份
填表人
填写日期
跟踪表版本
序
号
数据分析内容
数据分析结论
是
否
不
适
用
不
知
道
1
分配需求的更改
2
新的软件约定
3
对软件约定的更改
4
未来工作中可能出现新的软件风险
5
未来工作中可能需要新的关键资源
6
项目工作产品的规模的实际值与项目计划中的预计值相差 15%以上
7
项目工作产品的完成工期的实际值与项目计划中的预计值相差 15%以上
8
项目工作产品所花费的工作量和成本的实际值与项目计划中的预计值相差 15%以上
9
项目里程碑的完成日期点的的实际值与项目计划中的预计值相差时间值超过项目整个工期的 10%
10
出现重大的软件技术问题
11
资源不到位
12
13
14
15
不适用数据分析内容的证据,
课题组内部评审结论,
下月工作计划,
工程部经理审查意见,
需要更改项目计划吗？ ? 是 ? 否
附注,
课题工作月报
课题名称
阶段名称
填表人
填写日期
跟踪表版本
序
号
数据分析内容
数据分析结论
是
否
不
适
用
不
知
道
1
分配需求的更改
2
新的软件约定
3
对软件约定的更改
4
未来工作中可能出现新的软件风险
5
未来工作中可能需要新的关键资源
6
项目工作产品的规模的实际值与项目计划中的预计值相差 15%以上
7
项目工作产品的完成工期的实际值与项目计划中的预计值相差 15%以上
8
项目工作产品所花费的工作量和成本的实际值与项目计划中的预计值相差 15%以上
9
项目里程碑的完成日期点的的实际值与项目计划中的预计值相差时间值超过项目整个工期的 10%
10
出现重大的软件技术问题
11
资源不到位
12
13
14
15
不适用数据分析内容的证据,
课题组内部评审结论,
正式评审结论,
工程部经理审查意见,
需要更改项目计划吗？ ? 是 ? 否
附注,
阶段总结报告
什么是项目控制
? 项目控制是指在项目按事先制定的计划朝最终
目标挺进的过程中，由于前期工作的不确定性
和实施过程中多种因素的干扰，实施进展必然
会偏离轨道，为此，项目管理者根据项目追踪
提供的信息，对比原计划（即定目标），找出
偏差，分析成因，研究纠偏对策，实施纠偏措
施的全过程。
? 项目控制的目的是使项目按预定的轨迹运行和
实现。
项目控制原理
? 控制：为了改善某个或某些对象的功能
和发展，需要获得并使用信息，并以这
种信息为基础，加于该对象上的作用。
? 系统原理、反馈原理、封闭原理。
? 项目控制的三步曲原理,
? 寻找偏差
? 原因于趋势分析
? 采取纠偏行动
项目控制管理的范围
? 管理的人
? 团队的人员
? 客户的人
? 监控的任务
? 进度
? 成本
? 性能
项目控制的重要性
如果没有项目控制
? 项目的范围会很大的
? 成本会成倍增长
? 风险也会增加
? 进度也会推迟的
项目控制方法
? 传统项目控制以各种文件、报表、图表为 主要
工具,以定期、不定期会议为 主要方法 。
? 项目控制文件,合同、工作范围细则、职责划
分细则、项目程序细则、技术范围文件、计划
文件
? 项目控制会议：检查分析 里程碑完成情况、计
划未实现的影响、工作何时能完成、是否采取
纠偏措施、何时才能回到计划轨道、下一步活
动里程碑计划
控制过程
? 自动控制
? 通过 /通不过控制
? 采取检测方式看特定的先决条件是否被满足
? 项目用得最多的控制方式
? 在基本控制检查点进行
? 后控制
? 为改善未来项目实现目标的机会而设立
项目控制系统的设计
? 项目控制系统的组成
? 建立系统（目标）标
准
? 获得最新信息
? 偏差分析、评价
? 采取纠偏措施
? 通知所有有关部门
? 项目控制分析工具
? 偏差分析
? 趋势分析
? 关键比值
? 因果分析
项目控制系统
项目的三大控制权衡
? 质量控制
? 进度控制
? 控制权衡
? 在质量、成本、进度过程的约束三角形内完
成项目是科学、艺术、意志的完美结合。
? 如果项目超出了控制范围，想不牺牲范围、
预算、计划进度或质量就实现项目目标是困
难的。
制定基准计划
（进度计划、预算）
项目开始执行
在每个报告期内
收集实际进程数据
（进度、成本）
将变更修订进
项目计划
估算新的进度,
预算和预测
分析目前状况
与基准计划比较
确定纠正措施
协调相关变更
需要采取纠正
措施吗？
等到下一个
报告期
是
否
项目控制的步骤
? 建立标准
? 观察项目的性能,
? 将项目的实际结果与计划进行比较
? 如果实际的项目同计划有误差时，采取
必要的修正措施。
? 修正计划,通知有关人员和部门
图示分析法
? 进度 ---甘特图
? 成本 — 累 计费用曲线图
? 人力物力资源 — 资源载荷图
图示分析法－甘特图
图示分析法－ 累 计费用曲线
? 累计费用（ S） 曲线是项目累计支出图，
将每个月的支出加到以前的累计支出上，
就得到了平滑的、递增的计划和实际支
出的曲线
图示分析法－ 累 计费用曲线图
图示分析法－资源载荷图
分析决策
? 根据偏差确定是否需要修改计划,
? 项目工作产品的规模的实际值与项目计划中的预计
值相差 15%以上？
? 项目工作产品的完成工期的实际值与项目计划中的
预计值相差 15%以上？
? 项目工作产品所花费的工作量和成本的实际值与项
目计划中的预计值相差 15%以上？
? 项目里程碑的完成日期点的的实际值与项目计划中
的预计值相差时间值超过项目整个工期的 10%？
更改项目计划
? 明确修改内容
? 外部约定的更改与批准
? 受影响的组和个人参与和认可对约定的更改
? 按照软件项目策划过程修订项目计划，并形成文档。
必要时重新估计项目的规模、工作量、成本、进度、
关键资源，重新分析软件风险
? 对配置管理计划和质量保证计划进行相应修改
? 评审 项目计划更改
? 审查和批准对项目计划的修改
? 生成项目计划新版本并实施配置管理
? 将约定和计划的更改传达到相关组和个人
项目控制指南
?标示任务的完成情况
?评估推迟的任务
?评估完成的任务
?评估将要开始的任务
?评估项目的提交物
?提供重新评估的结果
?管理项目评审
?定期交流项目状况
?跟踪问题及其解决情况
对软件的特别建议 …
? 对 10%或以上的进度偏移的纠正，如果没有对软
件功能的 10%或更多的减少，或者成本、风险
10%或以上的增加，则是不可期望的。
? 对延误的软件项目增加更多的人手通常使其延误
更多。
? 在选取供应商之前允许需方和客户利用演示体验
软件产品的能力，可以缓解风险。
? 用原型开发软件功能的一部分来演示功能的适当
执行。
? 关键的系统工程工作的实施不能没有足够的软件
工程专门知识。
对软件的特别建议
? 与投资方合作，在项目过程中定期评审软件需求
基线，以调整目标（成本，进度，绩效）。
? 项目成员和小组的数目应当与预算和进度相联系，
正常的控制间距不应当被跨越。
? 由于软件的结果的显现是困难的，评估进展存在
许多困难。管理者必须定义和推敲确定进展的技
术，以在早期发现成本或进度的超越，或绩效的
不足。
? 由于软件开发和维护活动通常依赖个人的技巧和
经验，管理者应当努力防止在工作进行中不必要
地替换职员。
谢谢！
68389085（ O）
68389504（ H）
mdtang@btamail.net.cn
软件工程实践
汤铭端
中国航天科工集团公司 706所
第八讲
软件估计
软件项目跟踪与控制
内容和目的
? 了解软件估计的概念
? 掌握基本的软件估计方法
? 掌握软件项目追踪与控制的原理
? 了解软件项目追踪与控制的过程
软件估计
软件工作量估算
有些估算做得很仔细，而有些却只是
凭直觉的猜测。大多数项目超过估算进
度的 25%到 100％，但也有少数一些组织
的进度估算精确到了 10％以内，能控制
在 5％以内的还没有听说。
—— Jones,1994
软件工作量估算
,大多数 IS人士，无论是否为管理者，从来都无
权控制他们自己的进度计划。进度计划通常由
市场部或高层管理部门直接下达，就像飞石从
天而降（也有人称之为鸟粪）,
,就此问题，我曾与 IS领域中许多人士进行过交
流。大家一致认为当前 IS领域面临的最大难题，
既不是掌握快速更新的技术，也不是探求新型
的管理哲学，而是被迫接受根本无法达到的进
度计划。, （ Robert.L.Glass)
一个月的时间
造这样一栋房
子？没问题
太好了，那我
们开工吧！
你当初计划 10万元造的房屋可能最终的实际造价为 50万元。
从造房子中学到的
? 除非你确切知道, 它, 是什么？否则无
法说明它的确切花费。
? 盖房子时，可以盖梦想中的房子（不考
虑花费），也可以按估算盖，但是功能
必须具有一定的灵活性
软件工作量估算困难的原因
? 估算困难是由于软件的本质带来的，特别是其复杂性
和不可见性。
? 软件开发是人力密集型工作的，因而不能以机械的观
点来看待
? 传统的工程项目经常会议相近的项目做参考，不同的
只是客户和地点，而绝大部分软件项目是独一无二的。
? 新技术的不断出现和应用。
? 缺少项目经验数据，许多组织无法提供原有项目数据，
而即使提供了这些项目数据，也未必非常有用。
工作量估算的其它困难
? 某些人试图建立一个过去项目的全软件业的数
据库，但是许多词汇意义的不明确使得这种努
力没有效果，例如, 测试, 阶段究竟包括哪些
活动就不明确。
? 估计的主观性,人们容易低估小项目的工作量，
而过分夸大大项目的工作量
? 估计的政治因素,不同的人有不同的目标，如
项目经理会高估项目工作量，许多机构采用独
立的估算小组，但是将项目经理和项目成员吸
收进估算小组，能够增强他们的责任感。
何时需要估算
? 策略计划：选择合适的项目
? 可行性分析
? 系统描述：实现各个需求的工作量需要被衡量
? 评估供应商的建议
? 项目计划,
? 项目进行过程中，估算越来越准确
? 在项目开始阶段考虑的是用户需求，不考虑实现，
但是为了估算，有时需要考虑一些实现方法
过高估计和过低估计的问题
? 过高估计的问题
? Parkinson法则：给的时间越多，工作花费的时间也越多
? Brook法则：当人数增加后，项目所需的工作量 将不成比例
的增加。当团队规模变大后，由于管理，协调和通信的增加，
将造成工作量的增加。因而, 投入更多的人将使延期的工作
更加延期,
? 过低估计的问题
? 质量降低
? Weinberg的可靠性零法则, 如果系统不必可靠，那么它可以
满足任何目标, 。
工作量估算对职员的影响
? 如果职员能够完成目标，那么他们将受
到鼓舞
? 如果他们发现目标根本不能完成，那么
他们的激情将受到极大损害
? 因而，估计不是一种简单的预测行为，
而是一种管理目标
软件估算的基础
? 历史数据的需要
? 在参考历史数据时需要考虑不同的环境，如编程语言，
软件工具，标准和人员的经验。
? 工作度量
? 直接计算真正的成本或时间是不可能的。编写程序的时
间不同的人将有显著的区别。
? 通常将工作量表达为如源代码的数量（ source line of
code,SLOC）,或者千行代码量（ KLOC）
? 复杂性
? 相同 KLOC的两个程序花费的时间将会不同。因而不能简
单地应用 KLOC或 SLOC,而要根据复杂性进行修正，但是
复杂性的度量通常是主观而定的。
基于承诺的估计（后墙不倒）
? 一些组织直接从需求出发安排进度而不进行中
间的工作量估算。他们要求每个开发者作出进
度承诺而非进度估算。
? 有利于开发者对进度的关注，开发者在接受承
诺后士气高昂，自愿加班加点
? 问题在于开发者的估算比现实要乐观，大约低
20至 30个百分点（ Van Genuchten,1991)
? 承诺应该现实可行，以使你的团队会不断成功
而不是不断失败。
软件项目估计的对象内容
? 对象
? 项目
? 活动
? 工作包
? 内容
? 规模
? 工作量
? 持续时间（工期）
? 资源需求量
? 成本
估计量之间的关系
? 整体 =局部之和
? 工作量主要由规模确定
? 工作量 =资源数目 х工期
? 成本 =人力成本 +材料成本 +设备成本
? 人力成本 =工作量 х单位价格
软件估计方法
? 通用方法
? 1 类比方法
? 2 经验方法
? 3 模型方法
? 4 分解法
? 5 三点法
? 6 Delphi技术
? 规模、工作量、工期、
成本估计方法
? 7 自上而下
? 8 自下而上
? 9 生产率因子方法
? 10 功能点方法
? 11 COCOMO方法
? 12 IBM模型
1 类比方法
? 类比方法又被称为基于案例的推理（ Case-
based reasoning）
? 使用过去类似项目的确切数字，考虑与当前项目的差
异程度，来估计当前项目的相应数据。
当前项目估计 =参考项目数据×（ 1+差异百分比）
? 差异百分比当前项目比参考项目多（正）或少（负）
的百分比。
? 规模估计可以选取功能、输入输出等作为比较的参考
依据。
类比法示例
? 如当前项目系统与系统 XYZ类似
? XYZ系统的规模是 10K代码行
? 当前系统比 XYZ系统增加了约 10%的功能
? 对当前系统的规模估计是,
10K×（ 1+10%） =11K
2 经验方法（专家判断）
? 根据估计者自己的经验进行估计
? 具有应用领域知识的人员对任务的评估
? 该方法特别是在对原有系统进行替换时有用，评估
者对影响的代码的比例进行分析，从而得到工作量
评估
? 根据大家的共同经验进行估计
? 标准工法
? 标准工时
? 根据项目和项目组的具体情况进行调整
各阶段工作量分布
阶段
工作量分布比例
需求分析
18%
项目策划
5%
设计
20%
实现和集成
32%
测试
24%
形成产品
1%
3 模型方法（参数估算法）
? 是一种使用项目特性参数建立数据模型来估算的方法，
是一种统计技术，如回归分析和学习曲线。
? 模型可以简单也可以复杂
? 参考历史信息
? 重要参数必须量化处理
? 根据实际情况，对参数模型按适当比例调整
? 应该具有良好的数据库数据为基础
? 比较简单,而且也比较准确
? 是最常用的估算方法
? 如果模型选择不当或者数据不准,也会导致偏差
4 分解方法
? 进行整体估计感觉困难的时候，可以采用分解方法。
? 软件的功能结构、物理结构、软件项目的 WBS等都为分
解估计方法提供了参考框架。
? 如根据软件的功能结构（逻辑结构）和 /或软件（可能）
的物理结构，将软件进行逐步分解，直至分解到能够
对最小块进行较准确的估计。
? 分别采用基于经验的方法和 /或某种估计方法，对分解
得到的各块进行估计。
? 将这些子块的估计加在一起，获得对项目软件的整体
估计。
5 三点法（ Putnam模型）
? 假设估计是概率事件，服从 ?分布
? 通过估计
? 悲观（最大）值
? 最可能值
? 乐观（最小）值
? 加权平均的估计方法
估计期望值 =
（最大值 +4×最可能值 +最小值） /6
工作时间的分布与计算
三点法示例
? 若你认为软件规模,
? 最大值是 100K代码行
? 最小值是 50K代行
? 最可能值是 60K代码行
? 则加权平均所获得的规模估计初始期望
值为,
（ 50+4× 60+100） /6=65K代码行
6 德尔菲 (Delphi)方法
? 在难以获得经验、历史数据及专家时，可考虑采用德尔菲
方法作为一种有效的替代估计方法。
? 德尔菲方法通过群体的智慧和交流分析来获得不断趋向准
确和一致的估计结果。
? 过程：成立估计小组，首先介绍项目和产品情况，而后让
估计小组成员分别进行估计，结果（第一轮）以列表和
（或）直方图形式反馈给小组成员。在此基础上，估计值
比平均值相差大的人各自讲述自己的理由，然后再分别进
行下一次估计，得到新的估计结果（第二轮）。再次让小
组讨论后进行新的估计（第三轮）。在第三轮结果的基础
上进行最后的调整，得到的平均值就是估计结果。
? 通过上述估计和反馈过程，人们的估计会越来越接近，意
见更为统一，也就能得到综合各方面意见更为准确的结果。
宽带德尔菲 (Wide Band Delphi)
? 选择 3至 10名具有管理和估计经验的人员作为估计员
? 共同讨论和了解软件项目的目标、范围、需求、资源
? 分别按照各自的方法，对软件规模进行估计，并记录
? 分别分析项目估计的意外与风险，并确定估计风险与意外
调整百分比
? 分别根据其初始估计和估计风险与意外调整百分比，确定
各自的最后估计或最后估计范围。计算公式为,
? 最后估计 =初始估计×（ 1+意外调整百分比）
? 最后估计范围 =（ 1+[减少调整百分比，增加调整百分比 ]）
×初始估计
? 必要时，安排进行讨论和再评估，以便进一步取得一致
? 估计负责人对所有的最后估计进行平均，获得规模估计
7 从下向上方法
? 这种技术通常首先估计各个 独立工作,
然后再汇总从下往上估计整个项目
? 首先将项目分成部件任务，然后估算每
个任务
? 在大型的项目中，分解任务的过程是一
个叠代的过程，直到最下面的任务不可
分解，产生 WBS
从下向上估计法图示
工作包
从下向上估计法,
·估计工期
·估计资源
·估计费用
·估计工作量
8 从上往下 方法
? 同 从下向上 相反
? 从上往下逐步估计的
? 多在有 类似项目已 完成 的情况下应用
从上往上估计法图示
从上向下估计法,
·工作范围
·进度目标
·费用目标
9 生产率因子方法
? 假设在同等条件下开发速度（生产率）是一个常数。
? 各机构可以根据以前的工作经验和历史数据，获得生
产率因子。再根据估计的软件产品规模，估计项目的
工作量和持续时间。
? 确定项目产品的功能点
? 估计项目工作量和持续时间
5 功能点 /人月 ≤ 生产率因子 ≤9 功能点 /人月
生产率因子平均值 =8 功能点 /人月
工作量（人月） =功能点数 /生产率因子
持续月数 = 2.5×（工作量人月数） 0.38
? 各阶段工作量划分
10 功能点方法
? 代码行数与编程语言相关的，不具可比性
? 功能度量是一致的、可比的
? Albrecht功能点分析是由 Allan Albrecht在 IBM工作时
发明的自顶向下方法。
? 功能点法（ Function Points） 的基本点是计算机信息
系统包括五个主要部件或者外部用户类型，它们是,
? 外部输入：应用数据
? 外部输出：提供给用户的面向应用的信息
? 内部逻辑文件：逻辑主文件
? 外部接口文件：与其它系统交换信息
? 外部查询：在线的输入以获得立即的结果
功能点的计算
? 先进行核心计算获得未调整功能点（ UFP）,然后
用调整因子获得值调整因子（ VAF）,将 UFP乘以
VAF,就达到了调整功能点（ AFP）。
AFP=UFP× VAF
? UFP的计算：考虑五个功能分量：外部输入 EI,外
部输出 EO,外部查询 EQ,文件 EIF,外部接口 ILF。
UFP= IEI× EI+ IEO× EO+ IEQ× EQ+ IEIF× EIF+
ILIF× LIF
? VAF根据软件项目和软件产品的 14个相关属性计算
获得 。
未调整功能点 UFP计算公式
测量参数 计数 简单 平均 复杂
用户输入数
×
3 4 6 =
用户输出数
×
4 5 7 =
用户查询数
×
3 4 6 =
文件数
×
7 10 15 =
外部接口数
×
5 7 10 =
总计数值
×
=
五个功能分量
? 用户输入数,计算每个用户输入，它们向软件提供面向应用的数
据。输入应该与查询区分开来，分别计算。
? 用户输出数,计算每个用户输出，它们向用户提供面向应用的数
据。这里输出是指报表、屏幕、出错信息等。一个报表中的单个
数据项不单独计算。
? 用户查询数,一个查询被定义为一次联机输入，它导致软件以联
机输出的方式产生实时的响应。每一个不同的查询都要计算。
? 文件数,计算每个逻辑的主文件（如数据的一个逻辑组合。它可
能是某个大型数据库的一部分或一个独立的文件。）
? 外部接口数,计算所有机器可读的接口（如磁带或磁盘上的数据
文件），利用这些接口可以将信息从一个系统传送到另一个系统。
调整功能点 AFP计算公式
? AFP=UFP× [0.65+0.01× ∑Fi],I=1-14
? Fi是对影响产品规模的 14个因素进行分析确定
的, 复杂度调整值,,取值范围是 0-5
? Fi通过回答后面的问题后参照以下标尺得到
0 1 2 3 4 5
没有
影响
偶有
影响
轻微
影响
平均
影响
较大
影响
严重
影响
Fi
1,系统需要可靠的备份和复原吗？
2,需要数据通信吗？
3,有分布处理功能吗？
4,性能关键吗？
5,系统是否在一个已有的、很实用的操作环境中运行？
6,系统需要联机数据项吗？
7,联机数据项是否需要在多屏幕或多操作之间切换以完成输入？
8,需要联机更新主文件吗？
9,输入、输出、文件或查询很复杂吗？
10,内容处理复杂吗？
11,代码需要被设计成可重用吗？
12,设计中需要包括转换及安装吗？
13,系统的设计支持不同组织的多次安装吗？
14,应用的设计方便用户修改和使用吗？
功能点转换为代码行
? 通过定义各个功能点对应各种语言的代
码行数，则功能点可以转化为代码行
? 一些数据,
? Cobol,91
? C,128
? Quick Basic,64
? Object Oriented Languages,30
功能点和各种语言代码行对比
程序设计语言 LOC/FP 程序设计语言 LOC/FP
汇编语言 320 面向对象语言 30
C 128 第四代语言 20
COBOL 105 代码生成器 15
FORTRAN 105 电子表格 6
PASCAL 90 图形语言 4
ADA 70
功能点的扩充
? MarkII功能点
? 功能点 =-0.58× 输入数据元素＋ 1.66× 实体＋
0.26× 输出数据元素
? 特征点（ Feature Points):除了考虑普通功能点的内
容外，还考虑了算法的特征（矩阵转换，字符串解析，
处理中断等都是算法的例子）
? Boeing提出了一个三维功能点方法（ 3D） 其中三维为
数据维，功能维（输入转化为输出的步骤）和控制维
（状态之间的转换数）
? 对象点：计算需要处理的屏幕，报告和部件等（称为
对象）
11 COCOMO方法
? 构造性成本模型（ COnstructive COst MOdel）
? Barry Boehm 在二十世纪 70年代采用他的模型对 63个
项目进行了研究，由于其中只有 7个是商务系统，因而
它们不仅仅能被用于信息系统
? 当前使用最为广泛和最有效的估计软件项目开发成本
和工作量的方法
? 两个核心方程：用规模估计工作量；用工作量估计项
目持续时间
Effort = a× ( Size ) b
Tdev = c× ( Effort ) d
? Effort(人月 ),Size(KLOC),Tdev(月 )
COCOMO的层次
? 基本 COCOMO模型：将软件开发工作量（或成
本）作为程序规模的函数进行计算，程序规模
以估算的代码行表示
? 中级 COCOMO模型：将软件开发工作量（或成
本）作为程序规模及一组, 成本驱动因子, 的
函数来进行计算，其中, 成本驱动因子, 包括
对产品、硬件、人员、项目属性的主观评估
? 高级 COCOMO模型：包含了中级模型的所有特
征，并结合了, 成本驱动因子, 对软件工程过
程中每一个步骤（分析、设计等）的影响的评
估
COCOMO针对的软件项目类型
? 有机方式（ Organic）,主要关注数据处理、事务和数
据检索
? 较小的、简单的软件项目，有良好应用经验的小型
项目组，针对一组不是很严肃的需求开展工作
? 嵌入式方式（ Embedded）,基于硬件系统的集成部件
? 必须在一组严格的硬件、软件及操作约束下开发的
软件项目
? 半分离方式（ Semi-Detached）,介于有机方式和嵌入
式方式之间
? 一个中等的软件项目，具有不同经验水平的项目组
必须满足严格的及不严格的需求
基本 COCOMO的参数
a b c d
有机 2.4 1.05 2.5 0.38
半分离 3.0 1.12 2.5 0.35
嵌入 3.6 1.20 2.5 0.32
中级 COCOMO的公式和参数
a b
有机 2.8 1.05
半分离 3.0 1.12
嵌入 3.2 1.20
Effort = a× ( Size ) b× EAF
EAF= ΠＦ Ｉ (I=1-15)
? 产品属性
? RELY,所需的软件可靠性
? DATA,数据库的大小
? CPLX,产品复杂性
? 计算机属性
? TIME,执行时间方面的约束
? STOR,主存限制
? VIRT,虚拟机的易变性
? TURN,计算机周转时间
? 人员属性
? ACAP,分析员能力
? AEXP,应用领域中的实际经验
? PCAP,程序员能力
? VEXP,虚拟机使用经验
? LEXP,程序语言使用经验
? 项目属性
? MODP,现代程序设计方法
? TOOL,软件工具的使用
? SCED,所需的开发进度
ΠＦ Ｉ 表示 15个成本属性的取值连乘，从产品、计算机、人
员、项目等方面考虑
每个成本属性取值在 0.9至 1.4。平均情况下取 1.0；如果
对成本的影响较大取大于 1.0；否则取小于 1.0
高级模型
? 高级模型进一步对中级模型进行了两方
面的改进,
a,提出了针对不同开发阶段的成本属性因子
b,提出了成本属性因子按照模块级、子系统
级、系统级等三级产品层次结构变化和确定
COCOMO2.0
? 1995年形成适用面更宽、更为精确的改进模型 COCOMO2.0
? COCOMO2.0的核心公式与 COCOMO一致，但系数不同
? a取常参数 2.5,b变参数，由五个属性共同确定,
? PERC,开发先例
? FLEX,开发灵活性
? RESL,体系结构 /风险解决方案
? TEAM,小组凝聚力
? PMAT,过程成熟度
? 分别在 1.0周围取值 W1,W2,W3,W4,W5
? b = 1.01 + 0.01 ∑ Wi
12 IBM模型
? 总结 IBM的 60个项目数据，其中源代码从 400到
467000，开发工作量从 12人月到 11578人月，
使用了 29种编程语言和 66中不同的计算机。
E = 5.2 × L 0.91
D = 4.1 × L 0.36 = 2.47 × E 0.36
S = 0.54 × E 0.6
DOC = 49 × L 1.01
? 其中,E为开发工作量，单位为人月； D为项目
持续时间，单位为月； DOC为文档页数； L为源
代码行数； S为所需的开发人员数。
估算的技巧
? 避免无准备的估算
? 不要随口说出一个估算
? 留出估算的时间，并做好计划
? 估算本身也是一个项目
? 开发人员参与估算
? 不要忽略普通任务
? 使用几种不同的估算技术，并比较它们的结果
? 估算的群体讨论
过于乐观的进度计划
? Microsoft Word for Windows 1.0开发
? 包含 249,000行代码，投入 660人月，前后历时 5年，
实际花费时间为预期时间的 5倍
过于乐观的进度计划
? 导致 WinWord1.0开发延迟的几个主要因素,
? 项目初期制定的开发目标是不可实现的。盖茨下达的指示是
用最快的速度开发最好的字处理软件，争取在 12月内完成。
实现这两个目标中的任何一个都是困难的，同时达到则是不
可能的。
? 过紧的进度计划降低了计划的精确度。
? 开发过程中频繁换人。 5年中共换了 4个组长，其中有 2人因进
度压力离职,1人是出于健康的原因而离职。
? 迫于进度压力，开发人员匆忙写出一些低质量的和不完整的
代码，然后宣称已实现某些性能。这造成了 WinWord不得不将
用于提高软件稳定性的时间由预计的 3个月增加到 12个月。
? 由于该项目中，创新比速度更重要，因而试图缩短开发周期，反
而使周期变长
产生过于乐观的进度计划的根源
? 为了赶在某些特定时间前展示或出售产品。如计算机
交易展示会。
? 管理人员和客户拒绝接受仅给出范围的估算，而是按
照他们认为的, 最佳, 估算来制定进度计划。
? 项目管理人员和开发人员为了享受挑战的乐趣或在压
力下工作的刺激，而故意缩短进度计划。
? 管理部门和市场部门为了迎合客户而缩短进度计划。
? 项目管理人员认为较紧的进度计划能够使员工勤奋工
作。
? 原先的估计是合理的，但是在项目进行过程中又加进
了很多新特性，从而变成了过于乐观的进度。
? ……
过于乐观的进度计划的后果
? 进度计划准确性
进度完成日期
按期完成概率 开发人员一般
采用的较乐观
的进度计划
典型的过
分乐观的
进度计划
过于乐观的进度计划的后果
? 计划的质量：错误的假设必将导致无效的项目
规划。
? 抛弃计划：当面临进度压力时，大多数开发组
织会抛弃原有规划，而走入盲目开发的歧途。
? 如果试图在关键阶段节省时间，必将在后续阶
段加倍补偿。
? 分散了管理者的注意力：管理者将分散经历在
不断调整计划上。
? 客户关系：项目一拖再拖，客户将失去耐心。
过于乐观的进度计划的后果
? 仓卒收尾
? 要排错只能将系统拆分后再进行，一个小的变动要
花很长时间。
? 开发人员清楚地知道系统中存在一些应作修改却未
做的地方。
? 测试人员发现错误的速度大于开发人员排错的速度。
? 排除已发现错误的同时，产生了大量新的错误。
? 由于软件变化频繁，难以保证用户文档的同步更新。
? 项目估算多次调整，软件交付日期一拖再拖。
超负荷的进度压力
? 产品质量的降低
? 赌博心理导致风险管理的忽略
? 激励效应不再起作用
? 创造性思维受损
? 精疲力竭：在后面的项目中难以提起热情
? 中途退出：这些人通常是有能力的人
? 长期地进行快速开发：难以补充新知识
? 开发人员与管理人员的关系：不切实际的进度
压力会使开发人员丧失对管理人员的尊重 。
估算不准的原因
? 缺乏经验的估算人员
? 过分乐观
? 考虑不周
? 方法不一致
? 签约前后不连贯
? 低劣的推测技术
对付估算误差
? 避免低劣估算
? 处理低劣估算带来的后果
避免低劣估算
? 尽可能使企业的估算机构专业化
? 避免估算缺陷
? 过分乐观
? 政治压力
? 低劣估算模型
处理低劣估算带来的后果
? 通过数据说明资源不足,争取更多资源
? 强化变更管理程序
? 确定目标的优先次序
项目的追踪和控制
项目管理
? 制定计划
? 按计划去做
? 执行计划
? 检查计划的执行情况
? 控制对计划的偏差
对比
? 项目管理
? 计划
? 执行
? 追踪
? 控制
? PDCA环
? 计划
? 执行
? 检查
? 处理
项目的追踪和控制
? 计划、追踪、控制是项目管理不可分割
的三个环节
? 控制的基础是信息，信息的获得靠追踪
? 计划 -追踪 -控制是一个封闭循环，一个系
统过程，一个以信息为共同核心的相互
依赖、相互制约的互动过程。
? 计划 -追踪 -控制的主要对象是进度、成本、
质量
项目跟踪控制的定义
? 项目跟踪和控制是管理项目实施的两个
不同性质但却密切相关的活动
? 项目跟踪是项目控制的前提和条件
? 项目控制是项目跟踪的目的和服务对象
项目跟踪
? 在项目实施的全过程对项目进展的有关
情况以及影响项目实施的内外因素进行
及时的、连续的、系统的、准确的记录
和报告的一系列活动和过程。
? 目的是为项目管理者提供项目计划执行
情况的相关信息
项目控制
? 项目控制过程是为了保证项目成功和各
项目标的实现，对项目执行过程中出现
偏差采取必要的、有针对性的措施加以
纠正的过程。
? 项目控制是一个动态的过程，在不断获
取项目跟踪所得信息的基础上，要对所
发生的问题及时采取解决
项目跟踪控制的关系
跟踪系统 控制系统
信息
决策和命令
项目追踪和监督 — CMM的要求
活动 1 将已文档化的软件开发计划用于跟踪软件活动和
传送状态。
活动 2 按照已文档化的规程修订项目的软件开发计划。
活动 3 高级管理者参与按照已文档化的规程评审那些对
组织外部的个人和组所作的软件项目约定和约定的更
改。
活动 4 将经批准的、影响软件项目约定的更改传达给软
件工程组和其它软件－有关组的成员。
活动 5 跟踪软件工作产品的规模（或者软件工作产品更
改的规模），必要时采取纠正措施。
活动 6 跟踪项目的软件工作量和成本，必要时采取纠正
措施。
项目追踪和监督 — CMM的要求
活动 7 跟踪项目的关键计算机资源，必要时采取纠正措
施。
活动 8 跟踪项目的软件进度，必要时采取纠正措施。
活动 9 跟踪软件工程技术活动，必要时采取纠正措施。
活动 10 跟踪与项目的成本、资源、进度及技术方面有关
的软件风险。
活动 11 记录软件项目的实际测量数据和重新策划的数据。
活动 12 软件工程组进行定期的内部评审以便对照软件开
发计划跟踪技术进展、计划、性能和问题。
活动 13 按照已文档化的规程在所选择的项目里程碑处进
行正式评审以评价软件项目的完成情况和结果。
软件项目的追踪与控制
? 追踪
? 了解项目的进展情况
? 采集项目进展数据
? 统计分析
? 与计划对比
? 发现与计划的偏差
? 控制
? 分析偏差
? 决策是否调整计划
? 按规程调整计划
? 评审、实施、管理
跟踪内容
? 监督执行情况
? 测量和预测发展情况
项目跟踪系统
收集、输入 加工、处理、存储 报告、输出
信息
信息
项目追踪系统的设计 …
? 项目追踪对象
? 范围
? 变更
? 关键假设
? 资源供给
? 非项目时间
? 主要里程碑
? 进度
? 工作时间及任务完成情况
? 项目总结报告
? 收集信息范围
? 投入活动信息
? 采购活动信息
? 实施活动信息
? 项目产出信息
项目追踪系统的设计
? 项目追踪过程
? 观察
? 测量
? 分析
? 报告
项目追踪的方式
? 定期会议报告
? 项目组成员定期报告
? 里程碑检查
? 评审记录审查
? 软件质量保证人员报告
? 统计分析
? 与计划对比
软件项目追踪与控制过程
? 确定追踪元素
? 工作量、成本、进度、资源、风险
? 追踪
? 个人工作周记
? 项目工作月报
? 阶段总结报告
? 分析决策
? 计划
工作产品名称
规模
工作量
成本
开始日期
完成日期
计
划
实
际
计
划
实
际
计
划
实
际
计
划
实
际
计
划
实
际
规模、工作量、成本和进度跟踪表
序
号
名称
型号版本
数量
技术指标
使用起始日期
使用持续日期
备注
计
划
实
际
计
划
实
际
计划
实际
计
划
实
际
计
划
实
际
关键资源跟踪表
序
号
名称
型号版本
数量
技术指标
使用起始日期
使用持续日期
备注
计
划
实
际
计
划
实
际
计划
实际
计
划
实
际
计
划
实
际
风险跟踪表
课题名称
时段
填表人
岗位
填表日期
工作产品名称
完成比例
规模
投入时间
总体
新编
更新
总计
周 1
周 2
周
3
周
4
周 5
周 6
周日
工作陈述,
下周工作计划,
上级主管评语,
附注,
个人工作周报
进展度量准则
?完成百分比法
? 里程碑法 （ 0对 100法 ）
? 20对 80法
? 50对 50法
完成百分比法
? 已经完成的分活动和总的活动预算的百
分数
? 只有当你精确知道已经完成任务的百分
比时才能用该方法
? 该方法较为精确
里程碑法（ 0对 100法）
? 活动完成前一直是零
? 活动完成后为 100%
? 保守
20对 80法
? 活动开始前为的 0
? 开始后为 20%
? 完成后为 100%
50对 50法
? 活动开始前为 0
? 开始后为 50%
? 完成后为 100%
文档编制完成百分比计算方法
事件
工作完成百分比
启动
10
启动内部评审
50
完成内部评审
75
文档通过正式评审, 并已受到软件配置管理
100
短期工作完成百分比计算方法
事件
工作完成百分比
任务启动
50
任务完成
100
需求分析完成百分比计算方法
事件
工作完成百分比
任务启动
10
完成系统级需求和相关算法的定义
40
需求分类并详细说明
55
完成软件需求规格说明到系统规格说明的追踪
65
启动内部评审
75
完成内部评审
90
文档通过正式评审, 并已受到软件配置管理
100
设计工作完成百分比计算方法
事件
工作完成百分比
启动任务
10
完善数据流图, 定义相关算法
25
定义软件单元和结构关系
35
定义了每个软件单元的所有性能规格说明 /算法
50
定义了每个软件单元的接口规格说明
60
完成软件设计文档到软件需求规格说明的追踪
70
启动内部评审
80
完成内部评审
90
文档通过正式评审, 并已受到软件配置管理
100
程序开发完成百分比计算方法
事件
工作完成百分比
启动任务
10
完成编码
50
完成代码审查
60
完成代码单元测试
85
软件单元追踪到软件设计文档
95
代码存入软件配置管理库
100
测试设计完成百分比计算方法
事件
工作完成百分比
启动任务
10
确定测试用例设计原则
30
设计完测试用例
60
形成测试说明
75
启动内部评审
80
完成内部评审
90
测试说明存入软件配置管理库
100
课题名称
月 份
填表人
填写日期
跟踪表版本
序
号
数据分析内容
数据分析结论
是
否
不
适
用
不
知
道
1
分配需求的更改
2
新的软件约定
3
对软件约定的更改
4
未来工作中可能出现新的软件风险
5
未来工作中可能需要新的关键资源
6
项目工作产品的规模的实际值与项目计划中的预计值相差 15%以上
7
项目工作产品的完成工期的实际值与项目计划中的预计值相差 15%以上
8
项目工作产品所花费的工作量和成本的实际值与项目计划中的预计值相差 15%以上
9
项目里程碑的完成日期点的的实际值与项目计划中的预计值相差时间值超过项目整个工期的 10%
10
出现重大的软件技术问题
11
资源不到位
12
13
14
15
不适用数据分析内容的证据,
课题组内部评审结论,
下月工作计划,
工程部经理审查意见,
需要更改项目计划吗？ ? 是 ? 否
附注,
课题工作月报
课题名称
阶段名称
填表人
填写日期
跟踪表版本
序
号
数据分析内容
数据分析结论
是
否
不
适
用
不
知
道
1
分配需求的更改
2
新的软件约定
3
对软件约定的更改
4
未来工作中可能出现新的软件风险
5
未来工作中可能需要新的关键资源
6
项目工作产品的规模的实际值与项目计划中的预计值相差 15%以上
7
项目工作产品的完成工期的实际值与项目计划中的预计值相差 15%以上
8
项目工作产品所花费的工作量和成本的实际值与项目计划中的预计值相差 15%以上
9
项目里程碑的完成日期点的的实际值与项目计划中的预计值相差时间值超过项目整个工期的 10%
10
出现重大的软件技术问题
11
资源不到位
12
13
14
15
不适用数据分析内容的证据,
课题组内部评审结论,
正式评审结论,
工程部经理审查意见,
需要更改项目计划吗？ ? 是 ? 否
附注,
阶段总结报告
什么是项目控制
? 项目控制是指在项目按事先制定的计划朝最终
目标挺进的过程中，由于前期工作的不确定性
和实施过程中多种因素的干扰，实施进展必然
会偏离轨道，为此，项目管理者根据项目追踪
提供的信息，对比原计划（即定目标），找出
偏差，分析成因，研究纠偏对策，实施纠偏措
施的全过程。
? 项目控制的目的是使项目按预定的轨迹运行和
实现。
项目控制原理
? 控制：为了改善某个或某些对象的功能
和发展，需要获得并使用信息，并以这
种信息为基础，加于该对象上的作用。
? 系统原理、反馈原理、封闭原理。
? 项目控制的三步曲原理,
? 寻找偏差
? 原因于趋势分析
? 采取纠偏行动
项目控制管理的范围
? 管理的人
? 团队的人员
? 客户的人
? 监控的任务
? 进度
? 成本
? 性能
项目控制的重要性
如果没有项目控制
? 项目的范围会很大的
? 成本会成倍增长
? 风险也会增加
? 进度也会推迟的
项目控制方法
? 传统项目控制以各种文件、报表、图表为 主要
工具,以定期、不定期会议为 主要方法 。
? 项目控制文件,合同、工作范围细则、职责划
分细则、项目程序细则、技术范围文件、计划
文件
? 项目控制会议：检查分析 里程碑完成情况、计
划未实现的影响、工作何时能完成、是否采取
纠偏措施、何时才能回到计划轨道、下一步活
动里程碑计划
控制过程
? 自动控制
? 通过 /通不过控制
? 采取检测方式看特定的先决条件是否被满足
? 项目用得最多的控制方式
? 在基本控制检查点进行
? 后控制
? 为改善未来项目实现目标的机会而设立
项目控制系统的设计
? 项目控制系统的组成
? 建立系统（目标）标
准
? 获得最新信息
? 偏差分析、评价
? 采取纠偏措施
? 通知所有有关部门
? 项目控制分析工具
? 偏差分析
? 趋势分析
? 关键比值
? 因果分析
项目控制系统
项目的三大控制权衡
? 质量控制
? 进度控制
? 控制权衡
? 在质量、成本、进度过程的约束三角形内完
成项目是科学、艺术、意志的完美结合。
? 如果项目超出了控制范围，想不牺牲范围、
预算、计划进度或质量就实现项目目标是困
难的。
制定基准计划
（进度计划、预算）
项目开始执行
在每个报告期内
收集实际进程数据
（进度、成本）
将变更修订进
项目计划
估算新的进度,
预算和预测
分析目前状况
与基准计划比较
确定纠正措施
协调相关变更
需要采取纠正
措施吗？
等到下一个
报告期
是
否
项目控制的步骤
? 建立标准
? 观察项目的性能,
? 将项目的实际结果与计划进行比较
? 如果实际的项目同计划有误差时，采取
必要的修正措施。
? 修正计划,通知有关人员和部门
图示分析法
? 进度 ---甘特图
? 成本 — 累 计费用曲线图
? 人力物力资源 — 资源载荷图
图示分析法－甘特图
图示分析法－ 累 计费用曲线
? 累计费用（ S） 曲线是项目累计支出图，
将每个月的支出加到以前的累计支出上，
就得到了平滑的、递增的计划和实际支
出的曲线
图示分析法－ 累 计费用曲线图
图示分析法－资源载荷图
分析决策
? 根据偏差确定是否需要修改计划,
? 项目工作产品的规模的实际值与项目计划中的预计
值相差 15%以上？
? 项目工作产品的完成工期的实际值与项目计划中的
预计值相差 15%以上？
? 项目工作产品所花费的工作量和成本的实际值与项
目计划中的预计值相差 15%以上？
? 项目里程碑的完成日期点的的实际值与项目计划中
的预计值相差时间值超过项目整个工期的 10%？
更改项目计划
? 明确修改内容
? 外部约定的更改与批准
? 受影响的组和个人参与和认可对约定的更改
? 按照软件项目策划过程修订项目计划，并形成文档。
必要时重新估计项目的规模、工作量、成本、进度、
关键资源，重新分析软件风险
? 对配置管理计划和质量保证计划进行相应修改
? 评审 项目计划更改
? 审查和批准对项目计划的修改
? 生成项目计划新版本并实施配置管理
? 将约定和计划的更改传达到相关组和个人
项目控制指南
?标示任务的完成情况
?评估推迟的任务
?评估完成的任务
?评估将要开始的任务
?评估项目的提交物
?提供重新评估的结果
?管理项目评审
?定期交流项目状况
?跟踪问题及其解决情况
对软件的特别建议 …
? 对 10%或以上的进度偏移的纠正，如果没有对软
件功能的 10%或更多的减少，或者成本、风险
10%或以上的增加，则是不可期望的。
? 对延误的软件项目增加更多的人手通常使其延误
更多。
? 在选取供应商之前允许需方和客户利用演示体验
软件产品的能力，可以缓解风险。
? 用原型开发软件功能的一部分来演示功能的适当
执行。
? 关键的系统工程工作的实施不能没有足够的软件
工程专门知识。
对软件的特别建议
? 与投资方合作，在项目过程中定期评审软件需求
基线，以调整目标（成本，进度，绩效）。
? 项目成员和小组的数目应当与预算和进度相联系，
正常的控制间距不应当被跨越。
? 由于软件的结果的显现是困难的，评估进展存在
许多困难。管理者必须定义和推敲确定进展的技
术，以在早期发现成本或进度的超越，或绩效的
不足。
? 由于软件开发和维护活动通常依赖个人的技巧和
经验，管理者应当努力防止在工作进行中不必要
地替换职员。
谢谢！
68389085（ O）
68389504（ H）
mdtang@btamail.net.cn
