6.WorkloadEstimate项目管理项目估算.ppt

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