的差别。 • X功能的质量级别是什么？依据实施过程的不同，首次提交的X功能
的缺陷数量会有10％的差异。 • 调试和纠正X功能实施过程中的错误要花多少时间？研究发现调试和
纠正同样的错误，不同程序员所花时间会有10％左右的差异。 • 把X功能和其它功能结合起来要花多少时间？ • ……
6
软件工作量估算的渐进性
软件项目工作量估算
1
软件工作量估算
有些估算做得很仔细，而有些却只是凭直觉的猜测。大 多数项目超过估算进度的25%到100％，但也有少数一些 组织的进度估算精确到了10％以内，能控制在5％以内的 还没有听说。 ——Jones,1994
2
软件工作量估算
“大多数IS人士，无论是否为管理者，从来都无权控制他们自 己的进度计划。进度计划通常由市场部或高层管理部门直 接下达，就像飞石从天而降（也有人称之为鸟粪）”
“就此问题，我曾与IS领域中许多人士进行过交流。大家一 致认为当前IS领域面临的最大难题，既不是掌握快速更新 的技术，也不是探求新型的管理哲学，而是被迫接受根本 无法达到的进度计划。”（Robert.L.Glass)
3
太好了，那我 们开工吧！
一个月的时间 造这样一栋房 子？没问题
你当初计划10万元造的房屋可能最终的实际造价为50万元。
• 估计的政治因素：不同的人有不同的目标，如项目经理会 高估项目工作量，许多机构采用独立的估算小组，但是将 项目经理和项目成员吸收进估算小组，能够增强他们的责 任感。
11
何时需要度量//
• 策略计划：选择合适的项目 • 可行性分析 • 系统描述：实现各个需求的工作量需要被衡量 • 评估供应商的建议 • 项目计划：
部分 • 自下而上：各个部分的工作量先估算出来，然后进行合成
18
自底向上方法
• 该方法首先将项目分成部件任务，然后估算每个任务所需 的工作量。
• 在大型的项目中，分解任务的过程是一个叠代的过程，直 到最下面的任务不可分解，产生WBS。
• 该方法适合于项目规划的后期。如果应用在前期，那么必 须对最终的系统作出一些假设，例如对软件模块的数量和 大小进行假设。
– 项目进行过程中，估算越来越准确 – 在项目开始阶段考虑的是用户需求，不考虑实现，但是为了估算，
有时需要考虑一些实现方法
12
过高估计和过低估计的问题
• 过高估计的问题
– Parkinson法则：给的时间越多，工作花费的时间也越多 – Brook法则：当人数增加后，项目所需的工作量 将不成比例的增
7
估算的准确性和精确性
• 准确（accuracy）是结果与目标之间有多近，用3代表圆 周率比用4更准确
• 精确（precision）是结果有多少有意义的位数，3.14比3 代表圆周率更精确
• 一个结果可以不准确而精确，不精确而准确， • 软件估算中错误的精确是准确的敌人，40～70个人月的工
作量估算可能是最准确又最精确的估算，而精确到55个人 月看起来更精确，但不准确。
加。当团队规模变大后，由于管理，协调和通信的增加，将造成 工作量的增加。因而“投入更多的人将使延期的工作更加延期”
• 过低估计的问题
– 质量降低 – Weinberg的可靠性零法则“如果系统不必可靠，那么它可以满足
任何目标”。
13
工作量估算对职员的影响
• 如果职员能够完成目标，那么他们将受到鼓舞 • 如果他们发现目标根本不能完成，那么他们的激情将受到
极大损害 • 因而，估计不是一种简单的预测行为，而是一种管理目标
14
软件估算的基础（1）
• 历史数据的需要
– 在参考历史数据时需要考虑不同的环境，如编程语言，软件工具， 标准和人员的经验。
• 工作度量
– 直接计算真正的成本或时间是不可能的。编写程序的时间不同的 人将有显著的区别。
– 通常将工作量表达为工作量，如源代码的数量（source line of code，SLOC），或者千行代码量（KLOC）
• 有利于开发者对进度的关注，开发者在接受承诺后士气高 昂，自愿加班加点
• 问题在于开发者的估算比现实要乐观，大约低20至30个百 分点（Van Genuchten, 1991)
• 承诺应该现实可行，以使你的团队会不断成功而不是不断 失败。
17
软件工作量估计技术
• 算术模型 • 专家判断 • 对比法 • Parkinson：能够使用的参与该项目的人力 • 赢利价格：赢得合同的价格 • 自顶向下：首先定义整个项目的工作量，然后分解到各个
15
软件估算的基础（2）
• 复杂性
– 相同KLOC的两个程序花费的时间将会不同。因而不能简单地应用 KLOC或SLOC，而要根据复杂性进行修正，但是复杂性的度量通 常是主观而定的。
16
基于承诺的估计
• 一些组织直接从需求出发安排进度而不进行中间的工作量 估算。他们要求每个开发者作出进度承诺而非进度估算。
即使提供了这些项目数据，也未必非常有用。
9
例子
• 结论：很难用这些数据去估算项目
10
工作量估算的其它困难
• 某些人试图建立一个过去项目的全软件业的数据库，但是 许多词汇意义的不明确使得这种努力没有效果，例如“测 试”阶段究竟包括哪些活动就不明确。
• 估计的主观性：人们容易低估小项目的工作量，而过分夸 大大项目的工作量
8
软件工作量估算困难的原因
• 估算困难是由于软件的本质带来的，特别是其复杂性和不 可见性。
• 软件开发是人力密集型工作的，因而不能以机械的观点来 看待
• 传统的工程项目经常会议相近的项目做参考，不同的只是 客户和地点，而绝大部分软件项目是独一无二的。
• 新技术的不断出现和应用。 • 缺少项目经验数据，许多组织无法提供原有项目数据，而
4
从造房子中学到的
• 除非你确切知道“它”是什么？否则无法说明它的确切花 费。
• 盖房子时，可以盖梦想中的房子（不考虑花费），也可以 按估算盖，但是功能必须具有一定的灵活性
5
不确定性问题
• 客户会要求X功能吗？ • 客户要的是X功能的便宜版本还是昂贵版本呢？同一功能的不同版本
的实施难度至少有10％左右的差别。 • 如果实施了X功能的便宜版本，客户会不会以后又想要昂贵的版本。 • X功能如何设计？同一功能的不同设计，在复杂度方面会有10％左右