何时需要估算 ■策略计划:选择合适的项目 可行性分析 系统描述:实现各个需求的工作量需要被衡量 评估供应商的建议 项目计划: ■项目进行过程中,估算越来越准确 在项目开始阶段考虑的是用户需求,不考虑实现, 但是为了估算,有时需要考虑一些实现方法
何时需要估算 ◼ 策略计划：选择合适的项目 ◼ 可行性分析 ◼ 系统描述：实现各个需求的工作量需要被衡量 ◼ 评估供应商的建议 ◼ 项目计划： ◼ 项目进行过程中，估算越来越准确 ◼ 在项目开始阶段考虑的是用户需求，不考虑实现， 但是为了估算，有时需要考虑一些实现方法
过高估计和过低估计的问题 过高估计的问题 Parkinson法则:给的时间越多,工作花费的时间也越多 Brook法则:当人数增加后,项目所需的工作量将不成比例 的增加。当团队规模变大后,由于管理,协调和通信的增加 将造成工作量的增加。因而“投入更多的人将使延期的工作 更加延期 过低估计的问题 质量降低 Weinberg的可靠性零法则“如果系统不必可靠,那么它可以 满足任何目标
过高估计和过低估计的问题 ◼ 过高估计的问题 ◼ Parkinson法则：给的时间越多，工作花费的时间也越多 ◼ Brook法则：当人数增加后，项目所需的工作量 将不成比例 的增加。当团队规模变大后，由于管理，协调和通信的增加， 将造成工作量的增加。因而“投入更多的人将使延期的工作 更加延期” ◼ 过低估计的问题 ◼ 质量降低 ◼ Weinberg的可靠性零法则“如果系统不必可靠，那么它可以 满足任何目标”
工作量估算对职员的影响 如果职员能够完成目标,那么他们将受 到鼓舞 如果他们发现目标根本不能完成,那么 他们的激情将受到极大损害 因而,估计不是一种简单的预测行为 而是一种管理目标
工作量估算对职员的影响 ◼ 如果职员能够完成目标，那么他们将受 到鼓舞 ◼ 如果他们发现目标根本不能完成，那么 他们的激情将受到极大损害 ◼ 因而，估计不是一种简单的预测行为， 而是一种管理目标
软件估算的基础 历史数据的需要 ■在参考历史数据时需要考虑不同的环境,如编程语言, 软件工具,标准和人员的经验 工作度量 直接计算真正的成本或时间是不可能的。编写程序的时 间不同的人将有显著的区别。 通常将工作量表达为如源代码的数量( source line of code,SLOC),或者千行代码量(KLOC 复杂性 相同KLoC的两个程序花费的时间将会不同。因而不能 简单地应用KLOC或SLOC,而要根据复杂性进行修正, 但是复杂性的度量通常是主观而定的
软件估算的基础 ◼ 历史数据的需要 ◼ 在参考历史数据时需要考虑不同的环境，如编程语言， 软件工具，标准和人员的经验。 ◼ 工作度量 ◼ 直接计算真正的成本或时间是不可能的。编写程序的时 间不同的人将有显著的区别。 ◼ 通常将工作量表达为如源代码的数量（source line of code，SLOC），或者千行代码量（KLOC） ◼ 复杂性 ◼ 相同KLOC的两个程序花费的时间将会不同。因而不能 简单地应用KLOC或SLOC，而要根据复杂性进行修正， 但是复杂性的度量通常是主观而定的
基于承诺的估计(后墙不倒) 一些组织直接从需求出发安排进度而不进行中 门的工作量估算。他们要求每个开发者作出进 度承诺而非进度估算。 有利于开发者对进度的关注,开发者在接受承 诺后士气高昂,自愿加班加点 问题在于开发者的估算比现实要乐观,大约低 20至30个百分点( Van genuchten,1991) 承诺应该现实可行,以使你的团队会不断成功 而不是不断失败
基于承诺的估计（后墙不倒） ◼ 一些组织直接从需求出发安排进度而不进行中 间的工作量估算。他们要求每个开发者作出进 度承诺而非进度估算。 ◼ 有利于开发者对进度的关注，开发者在接受承 诺后士气高昂，自愿加班加点 ◼ 问题在于开发者的估算比现实要乐观，大约低 20至30个百分点（Van Genuchten, 1991) ◼ 承诺应该现实可行，以使你的团队会不断成功 而不是不断失败