关于软件规模估算的方法【转】

http://hi.baidu.com/sileader/blog/item/7ace5fddec2190dd8c102930.html

 

 

方法一、Delphi 法
方法二、 类比法
方法三、功能点估计法

 

 

 

http://bbs.vsharing.com/Article.aspx?aid=1098007

德尔菲方法：

 

 

一种项目估算的方法---DELPHI法

不要再预想出现奇迹
“我一开始怎么没想到？”作为一个不准确的项目估算带来的后果，这好象是经常听到的一句话。下面的DELPHI团队估算法可能会有些帮助
Karl Wiegers
作为软件开发者，经常会遇到工作量估算的问题，但是很少有人擅长于此。我们经常是太乐观，或者很快忘掉上一个项目延期的痛苦。将项目中的不确定性或风险用浮动时间来代替似乎不是一件简单的事情。并且在开始估算一个项目的时候，我们经常忽视某些活动的某些方面。这样当我们在实际过程中，或者会去执行这些不在计划列表中的任务，那样会超出我们的预期；或者会忽略这些任务，那样则会伤及项目的质量。
要成为一个好的项目估算者，有多种方式。最基本的方法是记录每一次估算的过程和假设，以及执行过程中的用时和工作量。实际结果与预算的比较能为今后的精确估算提供帮助。对于可能出现的遗漏重要工作的问题，这种将任务条目化的过程能够很好的避免。
另外一种方法是源于“三个臭皮匠能抵一个诸葛亮”的原则。DELPHI估算法是开始于1948年南德公司，这种方法首先让一小组相关专家无记名地给出自己对问题的估算，然后经过多次反复讨论以达成一致的估算结果。在七十年代早期，巴里褒曼和他的南德公司同事改进了这种方法，增加了更多团队间交互式的估算过程（见褒曼的《软件工程经济学》），从而创造了一种团队的DELPHI法。在这以后，Mary Sakry和 Neil Potter将其发展成为一种可重用的适用于软件项目的估算方法。
这种团队DELPHI法几乎可以用来估算项目中的任何事情，一个特定子系统开发所需要的人月数，一个完整产品的代码行数或者Class的个数，甚至要重新粉刷Bill Gates的别墅需要多少加仑的油漆也可以用这种方法估算出来。我曾经用该方法与一个过程改进小组一起估算过某特定的组织达到CMM2标准所需要的努力程度。
DELPHI法帮助你构造出一个详细的工作分解结构，这样一个工作分解结构是自底向上安排工作量或估算项目规模的基础。DELPHI过程的起点可以是待估算项目的一份规格说明书，也可以是初始的任务列表或项目计划。而该方法的结果应该包括详细的项目任务列表，与质量、过程相联系的具体事务列表，假设条件，以及项目的全局估算，最好是每块具体由单独一个成员负责给出。
图一给出了团队DELPHI过程的流程图。在计划阶段给出待估算问题的定义并选择参加人员。答疑会的目的是使所有的估算人员的思想集中