kangyimei-北航“软件工程与项目管理”讲义-6-XXXX课件

软件工程与项目管理SoftwareEngineeringandProjectManagementBeiHangCollegeofSoftwareOct.2010-Dec.2011康一梅kangyimei@软件工程与项目管理BeiHangCollegeofSo1第六讲软件估算第六讲软件估算2软件估算SoftwareEstimationInput：需求说明书系统设计对象设计变更请求Output：软件规模工作量进度软件估算SoftwareEstimationInput：3TheSoftware-EstimationStoryEstimation-ProcessOverviewSizeEstimationEffortEstimationScheduleEstimationEstimateRefinementSoftwareEstimation软件估算TheSoftware-EstimationStoryS4定义

估算的通常定义：对未来事实非零可能性的最乐观的预测。软件项目估算是指以准确的调查资料和项目信息(如人员和设备信息)为依据，从估算对象的历史，现状及其规律性出发，运用科学的方法，对估算对象的规模，所需工作量和成本进行的测定。SoftwareEstimation定义估算的通常定义：对未来事实非零可5介绍有些估算做的很仔细，而有些却只是凭直觉的猜测。大多数项目超过估算进度25%到100%，但也有少数一些组织的进度估算准确到10%以内，能控制在5%之内的还没有听说（Jones,1994)。

SoftwareEstimation介绍有些估算做的很仔细，而有些却只6介绍软件项目估算是项目计划的依据，但是大多数软件开发组织没有意识到软件估算的重要性。调查结果表明：35%的组织没有对软件开发的成本和时间作估算。50%的组织没有记录任何正在进行的项目的相关数据。57%的组织没有使用成本会计。80%的项目在成本或时间上超出预算。超出成本和时间的项目里仅有50%的是有意义的超出。进行了成本估算的组织里，62%的组织是基于感觉和经验，仅仅16%的组织使用了正式的估算方法，如成本估算模型。SoftwareEstimation介绍软件项目估算是项目计划的依据，但7CaseStudy案例

Carl负责Gaga-safe公司库存控制系统1.0版本的开发（ICS），在参加项目监督委员会第一次会议的时候，他对期望的功能已经有了总体设想。Bill是监督委员会的领导，他问：“Carl，ICS1.0需要多长时间？”Carl回答：“大概要9个月，不过这只是粗略的估算。”“不行，”Bill说，“我真希望你说3或4个月，我们一定要在6个月内拿出系统，能完成吗？”“我不能肯定，”Carl坦白地说，“我还得仔细研究一下，不过我相信可以找到办法在6个月内完成。”“那么把6个月当成项目完成的目标，”Bill说，“无论如何我们都必须这样做。”委员会的其他人一致同意了这个决定。到第五周的时候，又增加了一些产品概要设计工作，这使Carl更确信项目的时间更接近9个月而非6个月，然而他还是认为运气好的话有可能在6个月内完成项目。他不想被看作惹麻烦的人，所以决定等等再说。

——凭直觉的项目估算SoftwareEstimationCaseStudy案例Carl负责Gaga8CaseStudy案例（续）Carl的团队努力地工作着，进展稳定，但需求分析的时间比期望的要长。预定6个月要完成的项目已经过去4个月了。“2个月无论如何也做不完剩下的工作。”他只好告诉Bill，项目需要延长2个月，总共需要8个月时间。几个星期后Carl意识到设计进度也不像期望的那么快。“先做容易的部分，”他告诉项目组成员，“其余的部分遇到时再考虑。”Carl再次向监督委员会汇报：“8个月的项目已经过去7个月，详细设计基本完成，工作卓有成效，但是8个月内还是无法完成。”Carl通报了第2次进度拖延，并将完成时间定为10个月。Bill对拖延产生了抱怨，并要求Carl想办法仍将进度安排在8个月左右。第9个月，项目组完成了详细设计，但部分模块的编码还没有开始。Carl第3次要求要求延期——12个月。Bill?编码进行顺利，但一些地方需要重新设计和重新实现，而这些地方项目组没有把详细设计调整好，一些实现过程相互冲突。在第11个月的项目监督委员会上，Carl宣布了第4次项目延期——13个月。Bill？结果？……——凭直觉的项目估算SoftwareEstimationCaseStudy案例（续）9TheSoftware-EstimationStory软件估算与建筑预算一年的时间建这样一幢房子？没问题！太好了，那我们赶快开工吧！——软件与建筑SoftwareEstimationTheSoftware-EstimationStory软10TheSoftware-EstimationStory软件估算——软件开发是一个改进的过程盖一幢房子要花多少钱呢？这取决于房子本身。一个新的计费系统要花多少钱呢？这也取决于计费系统本身！一些组织希望在需求定义投入前就把成本估算的误差控制在10%以内，尽管项目估算的精确程度越早达到越好，但理论上是不可能实现的。如果真能那么早实现，精确度可以控制在2%以内。软件开发是一个逐步细化的过程，在每个阶段，都可能做出影响最终项目成本与进度的决策。SoftwareEstimationTheSoftware-EstimationStory软11TheSoftware-EstimationStory软件估算——可能细化的数量估算收敛图初始的产品定义批准的产品定义需求说明书产品设计说明书详细设计说明书产品完工项目成本（工作量和成本）项目进度1.0x1.0x4.0x2.0x1.5x1.25x0.8x0.67x0.5x0.25x1.6x1.25x1.15x1.1x0.9x0.85x0.8x0.6xSoftwareEstimationTheSoftware-EstimationStory软12TheSoftware-EstimationStory软件估算——可能细化的数量基于项目阶段的估算误差系数工作量和规模进度阶段乐观悲观乐观悲观初始产品定义0.254.00.601.60批准的产品定义0.502.00.801.25需求说明书0.671.500.851.15产品设计说明书0.801.250.901.10详细设计说明书0.901.100.951.05SoftwareEstimationTheSoftware-EstimationStory软13TheSoftware-EstimationStory软件估算——估算与控制功能资源功能资源项目的演变项目的演变产品规模产品规模功能趋于与可用的资源相匹配资源趋于与想得到的功能相匹配期望的功能与可用的资源大多数软件项目在开始时，期望的功能与可用的资源之间不匹配，但随着项目的进展，功能或资源（或两者）必定要互相匹配SoftwareEstimationTheSoftware-EstimationStory软14TheSoftware-EstimationStory软件估算——合作

表达你合作的意愿

估算既不要过高也不要过低，应该正好与费用相符。估算的目标是寻找估算与实际情况的交汇点。

精确与准确：航班时刻通常精确到分，但不准确。可能的最短软件开发进度是通过建立最可能的准确估算而不是最精确的估算达到的。如果想获得最快的开发速度，就要避免错误的精确。SoftwareEstimationTheSoftware-EstimationStory软15软件估算步骤确定软件范围确定工作所需资源确定估算内容估算改进SoftwareEstimation软件估算步骤确定软件范围SoftwareEstimatio16确定软件范围 确定软件估算范围，就是确定目标软件的数据和控制，功能，性能，约束，接口以及可靠性。软件估算步骤SoftwareEstimation确定软件范围 确定软件估算范围，就是确定目标软件的数据和控制17确定工作所需资源功能资源功能资源项目的演变项目的演变产品规模产品规模功能趋于与可用的资源相匹配资源趋于与想得到的功能相匹配期望的功能与可用的资源大多数软件项目在开始时，期望的功能与可用的资源之间不匹配，但随着项目的进展，功能或资源（或两者）必定要互相匹配软件估算步骤SoftwareEstimation确定工作所需资源功能资源功能资源项目的演变项目的演变产品产品18确定工作所需资源 可重用软件资源可分为以下几种：可直接复用的构件具有完全经验的构件具有部分经验的构件能够从第三方厂商获得或已经在以前的项目中使用过的软件，这些构件已经经过验证及确认，且可以直接用在当前的项目中。、以前在类似项目中建立的规约，设计，代码或测试数据，在本项目中需做修改。、以前在类似项目中建立的规约，设计，代码或测试数据，在本项目中需做实质上的修改。软件估算步骤SoftwareEstimation确定工作所需资源 可重用软件资源可分为以下几种：可直接复用的19确定估算内容

规模估算工作量估算进度估算成本估算缺陷数估算软件估算步骤SoftwareEstimation确定估算内容 规模估算软件估算步骤SoftwareEsti20规模估算

软件规模指的是非常普通意义上的软件总的范围。它包括功能集的深度和广度以及软件的难度和复杂性。规模估算方法有以下几种：用估算算法，如功能点方法，特征点，对象点，模糊逻辑，标准构件法，Delphi方法，PERT方法等。用规模估算软件。如果参与过类似的项目，并知道它的规模，那么按百分比形式估算新系统每个主要部分与旧系统相似部分的规模。每部分的规模加起来是总规模。软件估算步骤SoftwareEstimation规模估算 软件规模指的是非常普通意义上的软件总的范围。它包括21工作量估算

对软件所需的工作时间的估算，通常以人时，人天，人月，人年等单位来衡量。工作量估算可以采用以下方法进行：使用估算软件直接从规模估算得出使用组织中的历史数据确定具有已估算规模的先前的项目花了多少工作量。使用COCOMO模型或其他模型将代码行估算转换成工作量估算。采用Delphi方法，PERT方法等直接进行工作量估算。软件估算步骤SoftwareEstimation工作量估算 对软件所需的工作时间的估算，通常以人时，人天，人22进度估算

进度估算是针对以阶段为单位的估算，进度以不同阶段的里程碑作为标志，而不是对每一个细小任务都加以估算，对任务的适当分解很重要，分解的越细反而会不准确。进度估算可以采用以下方法进行：采用经验法，或Delphi方法，PERT方法等直接进行工作量估算。使用组织中的历史数据。使用COCOMO算法或其他算法的进度估算步骤，提供一种更好的估算。基于承诺的进度表。即将任务分解后，由承担任务的项目组成员给出进度承诺，这种方法许多时候非常有效。软件估算步骤SoftwareEstimation进度估算 进度估算是针对以阶段为单位的估算，进度以不同阶段的23进度估算方法

经验估算方法月进度=3.0*人月(1/3)例：65人月的工作量，进度=3.0*65(1/3)12个月5-6人（65/12）3.0,4.0,2.5SoftwareEstimation进度估算方法经验估算方法月进度=3.0*人月(24

由功能点计算进度的幂次软件类型最优级平均最差级系统软件0.430.450.48商业软件0.410.430.46封装商品软件0.390.420.45这个准则不能取代更仔细的进度估算，但它提供了一个获得粗略进度估算的最简单方法。Jones的一阶估算准则SoftwareEstimation进度估算方法由功能点计算进度的幂次软件类型最优级平均最差级系25成本估算

包括人力，设备，有形的，无形的支出成本估算，其中以人力与软硬件设备成本为主要部分。容易被忽视的是学习成本，培训成本，风险成本，维护成本等。人力成本主要基于工作量，进度估算。软件估算步骤SoftwareEstimation成本估算 包括人力，设备，有形的，无形的支出成本估算，其中以26缺陷数估算

包括需求，设计，代码中的缺陷，缺陷数影响项目的工作量，进度估算。通常以千行代码缺陷数等表示。缺陷数估算往往需要使用组织中的历史数据。软件估算步骤SoftwareEstimation缺陷数估算 包括需求，设计，代码中的缺陷，缺陷数影响项目的工27软件估算方法功能点估算（1984IBM方法）

输入输出查询内部逻辑文件外部接口文件项目早期，需求说明书面向数据库SoftwareEstimation软件估算方法功能点估算（1984IBM方法）28功能点估算（1984IBM方法）

功能点程序功能一般复杂中等复杂很复杂输入数量X3X4X6输出数量X4X5X7查询X3X4X6内部逻辑文件X7X10X15外部接口文件X5X7X10

按上表计算未调整的功能点总数然后根据14个对程序有影响的因素计算“影响系数”，这些因素包括数据通信、联机数据条目、处理复杂性和安装容易度等。影响系数在0.65到1.35之间。SoftwareEstimation软件估算方法功能点估算（1984IBM方法）29功能点估算（1984IBM方法）

功能点程序功能一般复杂中等复杂很复杂输入数量6X3=182X4=83X6=18输出数量7X4=287X5=350X7=0查询0X3=02X4=84X6=24内部逻辑文件5X7=352X10=203X15=45外部接口文件9X5=450X7=02X10=20未调整功能点总数304影响系数1.15调整后功能点总数350计算功能点数的例子SoftwareEstimation软件估算方法功能点估算（1984IBM方法）30Delphi’sWideband方法当许多专家基于相同假定独立地作出了相同估计，该估计多半是正确的必须确保专家针对相同的正确的假定进行工作SoftwareEstimation软件估算方法Delphi’sWideband方法当许多专家基于相同假定31Delphi’sWideband方法的步骤1.识别做估计的群组-专家估计者(4-6项目经理)-作者-估计协调者2.作者呈述待作估计的系统3.作者和专家一起识别作业和假定4.作者和专家一起就可接收的估计差异水准达成一致(例如20%)5.协调者整理一份群组所决定的作业清单，发给每个专家6.针对每个作业，专家独立地对每个作业作出估计（无讨论/咨询），将估计交给协调者7.协调者作出如下表格的综合：样表SoftwareEstimation软件估算方法Delphi’sWideband方法的步骤1.识别做估计的32Delphi’sWideband方法的步骤8.协调者将综合表发给全部专家和作者9.当%差别(variance)大于可接受水平时，专家与作者讨论作业和假定。不讨论估计值。某些作业可能作进一步分解或合并10.返回步骤5；继续工作直到全部作业处在可接受水平之内偏差率＝Max{(最大值－平均值),(平均值－最小值)}/平均值SoftwareEstimation软件估算方法Delphi’sWideband方法的步骤8.协调者将综合33Delphi’sWideband方法的关键绝对不讨论估计。讨论作业和假定估计是保密的。估计者不知道相互的估计应至少有三个估计者将项目分解到小的作业（约20个人日）SoftwareEstimation软件估算方法Delphi’sWideband方法的关键绝对不讨论估计。34PERT方法

PertSizing（PutnamBeta）方法是一种基于统计原理的估计方法，是一种简单易用、实效性强的软件估计方法。 对于指定的估计单元（可能是规模、进度、工作量等），由直接负责人给出估计结果，估计结果由3个值构成：最小值、最大值、最可能值，通过计算公式：

期望值=（最大规模+4*最可能规模+最小规模）/6

标准偏差=（最大规模-最小规模）/6得到估计的结果。SoftwareEstimation根据给出的三个值，推算出来最有可能接近实际值的规模。[期望值-标准偏差，期望值+标准偏差]是一个可以接受的规模估计范围，如果你的最终实际值能够落到该范围内，则可以被认为你的估计是成功的。初期该范围可以较大，随着估计的不断精确，该范围应该逐渐被有意识的减少以求得更准确的估计。建议：(最高-最低)/最可能<40％软件估算方法PERT方法PertSizing35PERT方法的应用

这种方法通常与WBS（任务分解）方法结合使用，可用于对于规模、进度、工作量的估计，通常用于规模估计，尤其适用于估计专家不足的情况。也可以和Delphi方法结合使用。SoftwareEstimation软件估算方法PERT方法的应用这种方法通常与WBS36PERT方法的角色SoftwareEstimation角色职责估计协调人估计协调人对项目熟悉，根据已实现的WBS来分配各任务给单元估计责任人。项目协调人将估计结果作为度量数据归入过程数据库。单元估计责任人单元估计责任人负责某个估计单元的估计结果估计员估计员一般是某项WBS的任务责任主体，他将负责该任务的开发。估计员凭借以往的开发经验和可参考的历史过程数据，对新任务的规模进行仔细的预测。软件估算方法PERT方法的角色SoftwareEstimation角色37PERT方法的改进点

1、根据实际估计结果，给出项目的实际值与最低、最高估计值的差距。 2、给出每模块实际值与最低、最高估计值的差距，计算准确估计的所占比率。 3、在多个项目估计的基础上，修正最低和最高值的建议范围，趋势减小。 4、收集项目估计过程中的问题，改进估计方法的每个步骤，并增加常见偏差指导。 5、项目估计值和实际值以及分析作为经验数据保存到过程数据库，供以后参考。SoftwareEstimation软件估算方法PERT方法的改进点1、根据实际估计结果，给出项目的38

将WBS、PERT、Delphi几种方法结合起来使用的示例

WBS是估算的基础，估算作业可以用WBS表给出，每个专家单独估算时采用PERT方法，而整个估算采用Delphi估算。假定一个软件系统分为5个功能模块，我们请5个专家对项目的需求、设计、编码、测试工作的工作量进行估算，工作量的单位是人月。SoftwareEstimation软件估算方法综合应用将WBS、PERT、Delphi几种方法结合起来使用的示39

将WBS、PERT、Delphi几种方法结合起来使用的示例

每个专家基于WBS、PERT方法单独进行估算的示例SoftwareEstimation软件估算方法综合应用作业乐观估计悲观估计最可能估计偏差功能模块1需求设计编码测试功能模块2需求设计编码测试将WBS、PERT、Delphi几种方法结合起来使用的示40

将WBS、PERT、Delphi几种方法结合起来使用的示例WBS、PERT、Delphi综合应用进行工作量估算的示例SoftwareEstimation软件估算方法综合应用作业专家1估算值专家2估算值专家3估算值专家4估算值专家5估算值偏差率功能模块1需求设计编码测试功能模块2需求设计编码测试将WBS、PERT、Delphi几种方法结合起来使用的示41估算的表达方式加减限定范围风险量化情况粗略的日期和时间段把握性因素SoftwareEstimation估算的表达方式加减限定SoftwareEstimation42加减限定范围风险量化情况粗略的日期和时间段把握性因素估算：6个月，+3个月，-2个月+1个月延迟交付图形格式子系统-1个月招聘开发人员比预计少+1个月新开发工具没有希望的好用-1个月新开发工具比预期的好用+0.5个月员工病假+0.5个月低估规模SoftwareEstimation估算的表达方式加减限定估算：6个月，+3个月，-2个月+1个月延迟交付图形43加减限定范围风险量化情况粗略的日期和时间段把握性因素情况估算最佳情况4月1日计划情况5月15日当前情况5月30日最差情况6月15日SoftwareEstimation估算的表达方式加减限定情况估算最佳情况4月1日计划情况5月15日当前情况544加减限定范围风险量化情况粗略的日期和时间段把握性因素交付日期按期或提前交付的概率4月1日5%5月1日50%6月1日95%SoftwareEstimation估算的表达方式加减限定交付日期按期或提前交付的概率4月1日5%5月1日5045估算改进单点估算例子项目点估算（人月）初始产品概念阶段100已批准的产品概念阶段100需求说明书阶段135概要设计说明书阶段145详细设计说明书阶段160结束阶段170SoftwareEstimation估算改进单点估算例子项目点估算（人月）初始产品概念阶段1046范围估算例子项目点估算（人月）初始产品概念阶段25-400已批准的产品概念阶段50-200需求说明书阶段90-200概要设计说明书阶段120-180详细设计说明书阶段145-180结束阶段170SoftwareEstimation估算改进范围估算例子项目点估算（人月）初始产品概念阶段25-40047估算再修正的例子假定有一个6个月的进度计划，计划4周完成第一个里程碑，而实际用了5周。这时：假定能在后续进度中弥补损失的一周？把这一周加到整个进度中？把整个进度乘以拖延的数量（比例），本例中为25%？SoftwareEstimation估算改进估算再修正的例子假定有一个6个月的进度计划，计划4周48软件估算的原则与技巧

估算时间越早，错误越大，但仍然要在项目初期就开始估算。估算的目的是用来做决策，而不是估算完成就完了。留出估算的时间，并做好计划。避免无准备的估算。估算文档化做得越好，获得估算经验的机会越大，这些经验可以为以后的项目估算提供参考使用以前项目的数据。使用以开发人员为基础的估算。进行详细的较低层次上的估算。不要忽略普通任务。走查估算。使用软件工具估算。使用几种不同的估算方法。估算的目的是得到准确的结果，不是寻求特定的结果。SoftwareEstimation数据转换、安装、定制、B测试程序管理、向客户或用户演示程序、参加变更控制会议、项目进行中现有系统的维护与技术支持、缺陷修正、与SQA的协调、用户文档支持、技术文档评审、集成、休假、节假日、员工病假、公司和部门会议、培训等项目组成员分别估算项目的各个部分，然后开一个走查会议比较所有的估算。充分讨论估算的差别并了解出现差别的原因，一直到估算范围的高低界限达成一致意见才算完成。软件估算的原则与技巧 估算时间越早，错误越大，但仍然要在项目49软件工程与项目管理SoftwareEngineeringandProjectManagementBeiHangCollegeofSoftwareOct.2010-Dec.2011康一梅kangyimei@软件工程与项目管理BeiHangCollegeofSo50第六讲软件估算第六讲软件估算51软件估算SoftwareEstimationInput：需求说明书系统设计对象设计变更请求Output：软件规模工作量进度软件估算SoftwareEstimationInput：52TheSoftware-EstimationStoryEstimation-ProcessOverviewSizeEstimationEffortEstimationScheduleEstimationEstimateRefinementSoftwareEstimation软件估算TheSoftware-EstimationStoryS53定义

估算的通常定义：对未来事实非零可能性的最乐观的预测。软件项目估算是指以准确的调查资料和项目信息(如人员和设备信息)为依据，从估算对象的历史，现状及其规律性出发，运用科学的方法，对估算对象的规模，所需工作量和成本进行的测定。SoftwareEstimation定义估算的通常定义：对未来事实非零可54介绍有些估算做的很仔细，而有些却只是凭直觉的猜测。大多数项目超过估算进度25%到100%，但也有少数一些组织的进度估算准确到10%以内，能控制在5%之内的还没有听说（Jones,1994)。

SoftwareEstimation介绍有些估算做的很仔细，而有些却只55介绍软件项目估算是项目计划的依据，但是大多数软件开发组织没有意识到软件估算的重要性。调查结果表明：35%的组织没有对软件开发的成本和时间作估算。50%的组织没有记录任何正在进行的项目的相关数据。57%的组织没有使用成本会计。80%的项目在成本或时间上超出预算。超出成本和时间的项目里仅有50%的是有意义的超出。进行了成本估算的组织里，62%的组织是基于感觉和经验，仅仅16%的组织使用了正式的估算方法，如成本估算模型。SoftwareEstimation介绍软件项目估算是项目计划的依据，但56CaseStudy案例

Carl负责Gaga-safe公司库存控制系统1.0版本的开发（ICS），在参加项目监督委员会第一次会议的时候，他对期望的功能已经有了总体设想。Bill是监督委员会的领导，他问：“Carl，ICS1.0需要多长时间？”Carl回答：“大概要9个月，不过这只是粗略的估算。”“不行，”Bill说，“我真希望你说3或4个月，我们一定要在6个月内拿出系统，能完成吗？”“我不能肯定，”Carl坦白地说，“我还得仔细研究一下，不过我相信可以找到办法在6个月内完成。”“那么把6个月当成项目完成的目标，”Bill说，“无论如何我们都必须这样做。”委员会的其他人一致同意了这个决定。到第五周的时候，又增加了一些产品概要设计工作，这使Carl更确信项目的时间更接近9个月而非6个月，然而他还是认为运气好的话有可能在6个月内完成项目。他不想被看作惹麻烦的人，所以决定等等再说。

——凭直觉的项目估算SoftwareEstimationCaseStudy案例Carl负责Gaga57CaseStudy案例（续）Carl的团队努力地工作着，进展稳定，但需求分析的时间比期望的要长。预定6个月要完成的项目已经过去4个月了。“2个月无论如何也做不完剩下的工作。”他只好告诉Bill，项目需要延长2个月，总共需要8个月时间。几个星期后Carl意识到设计进度也不像期望的那么快。“先做容易的部分，”他告诉项目组成员，“其余的部分遇到时再考虑。”Carl再次向监督委员会汇报：“8个月的项目已经过去7个月，详细设计基本完成，工作卓有成效，但是8个月内还是无法完成。”Carl通报了第2次进度拖延，并将完成时间定为10个月。Bill对拖延产生了抱怨，并要求Carl想办法仍将进度安排在8个月左右。第9个月，项目组完成了详细设计，但部分模块的编码还没有开始。Carl第3次要求要求延期——12个月。Bill?编码进行顺利，但一些地方需要重新设计和重新实现，而这些地方项目组没有把详细设计调整好，一些实现过程相互冲突。在第11个月的项目监督委员会上，Carl宣布了第4次项目延期——13个月。Bill？结果？……——凭直觉的项目估算SoftwareEstimationCaseStudy案例（续）58TheSoftware-EstimationStory软件估算与建筑预算一年的时间建这样一幢房子？没问题！太好了，那我们赶快开工吧！——软件与建筑SoftwareEstimationTheSoftware-EstimationStory软59TheSoftware-EstimationStory软件估算——软件开发是一个改进的过程盖一幢房子要花多少钱呢？这取决于房子本身。一个新的计费系统要花多少钱呢？这也取决于计费系统本身！一些组织希望在需求定义投入前就把成本估算的误差控制在10%以内，尽管项目估算的精确程度越早达到越好，但理论上是不可能实现的。如果真能那么早实现，精确度可以控制在2%以内。软件开发是一个逐步细化的过程，在每个阶段，都可能做出影响最终项目成本与进度的决策。SoftwareEstimationTheSoftware-EstimationStory软60TheSoftware-EstimationStory软件估算——可能细化的数量估算收敛图初始的产品定义批准的产品定义需求说明书产品设计说明书详细设计说明书产品完工项目成本（工作量和成本）项目进度1.0x1.0x4.0x2.0x1.5x1.25x0.8x0.67x0.5x0.25x1.6x1.25x1.15x1.1x0.9x0.85x0.8x0.6xSoftwareEstimationTheSoftware-EstimationStory软61TheSoftware-EstimationStory软件估算——可能细化的数量基于项目阶段的估算误差系数工作量和规模进度阶段乐观悲观乐观悲观初始产品定义0.254.00.601.60批准的产品定义0.502.00.801.25需求说明书0.671.500.851.15产品设计说明书0.801.250.901.10详细设计说明书0.901.100.951.05SoftwareEstimationTheSoftware-EstimationStory软62TheSoftware-EstimationStory软件估算——估算与控制功能资源功能资源项目的演变项目的演变产品规模产品规模功能趋于与可用的资源相匹配资源趋于与想得到的功能相匹配期望的功能与可用的资源大多数软件项目在开始时，期望的功能与可用的资源之间不匹配，但随着项目的进展，功能或资源（或两者）必定要互相匹配SoftwareEstimationTheSoftware-EstimationStory软63TheSoftware-EstimationStory软件估算——合作

表达你合作的意愿

估算既不要过高也不要过低，应该正好与费用相符。估算的目标是寻找估算与实际情况的交汇点。

精确与准确：航班时刻通常精确到分，但不准确。可能的最短软件开发进度是通过建立最可能的准确估算而不是最精确的估算达到的。如果想获得最快的开发速度，就要避免错误的精确。SoftwareEstimationTheSoftware-EstimationStory软64软件估算步骤确定软件范围确定工作所需资源确定估算内容估算改进SoftwareEstimation软件估算步骤确定软件范围SoftwareEstimatio65确定软件范围 确定软件估算范围，就是确定目标软件的数据和控制，功能，性能，约束，接口以及可靠性。软件估算步骤SoftwareEstimation确定软件范围 确定软件估算范围，就是确定目标软件的数据和控制66确定工作所需资源功能资源功能资源项目的演变项目的演变产品规模产品规模功能趋于与可用的资源相匹配资源趋于与想得到的功能相匹配期望的功能与可用的资源大多数软件项目在开始时，期望的功能与可用的资源之间不匹配，但随着项目的进展，功能或资源（或两者）必定要互相匹配软件估算步骤SoftwareEstimation确定工作所需资源功能资源功能资源项目的演变项目的演变产品产品67确定工作所需资源 可重用软件资源可分为以下几种：可直接复用的构件具有完全经验的构件具有部分经验的构件能够从第三方厂商获得或已经在以前的项目中使用过的软件，这些构件已经经过验证及确认，且可以直接用在当前的项目中。、以前在类似项目中建立的规约，设计，代码或测试数据，在本项目中需做修改。、以前在类似项目中建立的规约，设计，代码或测试数据，在本项目中需做实质上的修改。软件估算步骤SoftwareEstimation确定工作所需资源 可重用软件资源可分为以下几种：可直接复用的68确定估算内容

规模估算工作量估算进度估算成本估算缺陷数估算软件估算步骤SoftwareEstimation确定估算内容 规模估算软件估算步骤SoftwareEsti69规模估算

软件规模指的是非常普通意义上的软件总的范围。它包括功能集的深度和广度以及软件的难度和复杂性。规模估算方法有以下几种：用估算算法，如功能点方法，特征点，对象点，模糊逻辑，标准构件法，Delphi方法，PERT方法等。用规模估算软件。如果参与过类似的项目，并知道它的规模，那么按百分比形式估算新系统每个主要部分与旧系统相似部分的规模。每部分的规模加起来是总规模。软件估算步骤SoftwareEstimation规模估算 软件规模指的是非常普通意义上的软件总的范围。它包括70工作量估算

对软件所需的工作时间的估算，通常以人时，人天，人月，人年等单位来衡量。工作量估算可以采用以下方法进行：使用估算软件直接从规模估算得出使用组织中的历史数据确定具有已估算规模的先前的项目花了多少工作量。使用COCOMO模型或其他模型将代码行估算转换成工作量估算。采用Delphi方法，PERT方法等直接进行工作量估算。软件估算步骤SoftwareEstimation工作量估算 对软件所需的工作时间的估算，通常以人时，人天，人71进度估算

进度估算是针对以阶段为单位的估算，进度以不同阶段的里程碑作为标志，而不是对每一个细小任务都加以估算，对任务的适当分解很重要，分解的越细反而会不准确。进度估算可以采用以下方法进行：采用经验法，或Delphi方法，PERT方法等直接进行工作量估算。使用组织中的历史数据。使用COCOMO算法或其他算法的进度估算步骤，提供一种更好的估算。基于承诺的进度表。即将任务分解后，由承担任务的项目组成员给出进度承诺，这种方法许多时候非常有效。软件估算步骤SoftwareEstimation进度估算 进度估算是针对以阶段为单位的估算，进度以不同阶段的72进度估算方法

经验估算方法月进度=3.0*人月(1/3)例：65人月的工作量，进度=3.0*65(1/3)12个月5-6人（65/12）3.0,4.0,2.5SoftwareEstimation进度估算方法经验估算方法月进度=3.0*人月(73

由功能点计算进度的幂次软件类型最优级平均最差级系统软件0.430.450.48商业软件0.410.430.46封装商品软件0.390.420.45这个准则不能取代更仔细的进度估算，但它提供了一个获得粗略进度估算的最简单方法。Jones的一阶估算准则SoftwareEstimation进度估算方法由功能点计算进度的幂次软件类型最优级平均最差级系74成本估算

包括人力，设备，有形的，无形的支出成本估算，其中以人力与软硬件设备成本为主要部分。容易被忽视的是学习成本，培训成本，风险成本，维护成本等。人力成本主要基于工作量，进度估算。软件估算步骤SoftwareEstimation成本估算 包括人力，设备，有形的，无形的支出成本估算，其中以75缺陷数估算

包括需求，设计，代码中的缺陷，缺陷数影响项目的工作量，进度估算。通常以千行代码缺陷数等表示。缺陷数估算往往需要使用组织中的历史数据。软件估算步骤SoftwareEstimation缺陷数估算 包括需求，设计，代码中的缺陷，缺陷数影响项目的工76软件估算方法功能点估算（1984IBM方法）

输入输出查询内部逻辑文件外部接口文件项目早期，需求说明书面向数据库SoftwareEstimation软件估算方法功能点估算（1984IBM方法）77功能点估算（1984IBM方法）

功能点程序功能一般复杂中等复杂很复杂输入数量X3X4X6输出数量X4X5X7查询X3X4X6内部逻辑文件X7X10X15外部接口文件X5X7X10

按上表计算未调整的功能点总数然后根据14个对程序有影响的因素计算“影响系数”，这些因素包括数据通信、联机数据条目、处理复杂性和安装容易度等。影响系数在0.65到1.35之间。SoftwareEstimation软件估算方法功能点估算（1984IBM方法）78功能点估算（1984IBM方法）

功能点程序功能一般复杂中等复杂很复杂输入数量6X3=182X4=83X6=18输出数量7X4=287X5=350X7=0查询0X3=02X4=84X6=24内部逻辑文件5X7=352X10=203X15=45外部接口文件9X5=450X7=02X10=20未调整功能点总数304影响系数1.15调整后功能点总数350计算功能点数的例子SoftwareEstimation软件估算方法功能点估算（1984IBM方法）79Delphi’sWideband方法当许多专家基于相同假定独立地作出了相同估计，该估计多半是正确的必须确保专家针对相同的正确的假定进行工作SoftwareEstimation软件估算方法Delphi’sWideband方法当许多专家基于相同假定80Delphi’sWideband方法的步骤1.识别做估计的群组-专家估计者(4-6项目经理)-作者-估计协调者2.作者呈述待作估计的系统3.作者和专家一起识别作业和假定4.作者和专家一起就可接收的估计差异水准达成一致(例如20%)5.协调者整理一份群组所决定的作业清单，发给每个专家6.针对每个作业，专家独立地对每个作业作出估计（无讨论/咨询），将估计交给协调者7.协调者作出如下表格的综合：样表SoftwareEstimation软件估算方法Delphi’sWideband方法的步骤1.识别做估计的81Delphi’sWideband方法的步骤8.协调者将综合表发给全部专家和作者9.当%差别(variance)大于可接受水平时，专家与作者讨论作业和假定。不讨论估计值。某些作业可能作进一步分解或合并10.返回步骤5；继续工作直到全部作业处在可接受水平之内偏差率＝Max{(最大值－平均值),(平均值－最小值)}/平均值SoftwareEstimation软件估算方法Delphi’sWideband方法的步骤8.协调者将综合82Delphi’sWideband方法的关键绝对不讨论估计。讨论作业和假定估计是保密的。估计者不知道相互的估计应至少有三个估计者将项目分解到小的作业（约20个人日）SoftwareEstimation软件估算方法Delphi’sWideband方法的关键绝对不讨论估计。83PERT方法

PertSizing（PutnamBeta）方法是一种基于统计原理的估计方法，是一种简单易用、实效性强的软件估计方法。 对于指定的估计单元（可能是规模、进度、工作量等），由直接负责人给出估计结果，估计结果由3个值构成：最小值、最大值、最可能值，通过计算公式：

期望值=（最大规模+4*最可能规模+最小规模）/6

标准偏差=（最大规模-最小规模）/6得到估计的结果。SoftwareEstimation根据给出的三个值，推算出来最有可能接近实际值的规模。[期望值-标准偏差，期望值+标准偏差]是一个可以接受的规模估计范围，如果你的最终实际值能够落到该范围内，则可以被认为你的估计是成功的。初期该范围可以较大，随着估计的不断精确，该范围应该逐渐被有意识的减少以求得更准确的估计。建议：(最高-最低)/最可能<40％软件估算方法PERT方法PertSizing84PERT方法的应用

这种方法通常与WBS（任务分解）方法结合使用，可用于对于规模、进度、工作量的估计，通常用于规模估计，尤其适用于估计专家不足的情况。也可以和Delphi方法结合使用。SoftwareEstimation软件估算方法PERT方法的应用这种方法通常与WBS85PERT方法的角色SoftwareEstimation角色职责估计协调人估计协调人对项目熟悉，根据已实现的WBS来分配各任务给单元估计责任人。项目协调人将估计结果作为度量数据归入过程数据库。单元估计责任人单元估计责任人负责某个估计单元的估计结果估计员估计员一般是某项WBS的任务责任主体，他将负责该任务的开发。估计员凭借以往的开发经验和可参考的历史过程数据，对新任务的规模进行仔细的预测。软件估算方法PERT方法的角色SoftwareEstimation角色86PERT方法的改进点

1、根据实际估计结果，给出项目的实际值与最低、最高估计值的差距。 2、给出每模块实际值与最低、最高估计值的差距，计算准确估计的所占比率。 3、在多个项目估计的基础上，修正最低和最高值的建议范围，趋势减小。 4、收集项目估计过程中的问题，改进估计方法的每个步骤，并增加常见偏差指导。 5、项目估计值和实际值以及分析作为经验数据保存到过程数据库，供以后参考。SoftwareEstima