《《软件估算讲义》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《软件估算讲义》PPT课件.ppt（48页珍藏版）》请在三一办公上搜索。
1、,第六讲,软件估算,软件估算,Software Estimation,Input：需求说明书 系统设计 对象设计 变更请求Output：软件规模 工作量 进度,The Software-Estimation StoryEstimation-Process OverviewSize EstimationEffort EstimationSchedule EstimationEstimate Refinement,Software Estimation,软件估算,定义,估算的通常定义：对未来事实非零可能性的最乐观的预测。软件项目估算是指以准确的调查资料和项目信息(如人员和设备信息)为依据，从估算对
2、象的历史，现状及其规律性出发，运用科学的方法，对估算对象的规模，所需工作量和成本进行的测定。,Software Estimation,介绍,有些估算做的很仔细，而有些却只是凭直觉的猜测。大多数项目超过估算进度25%到100%，但也有少数一些组织的进度估算准确到10%以内，能控制在5%之内的还没有听说（Jones,1994)。,Software Estimation,介绍,软件项目估算是项目计划的依据，但是大多数软件开发组织没有意识到软件估算的重要性。调查结果表明：,35%的组织没有对软件开发的成本和时间作估算。50%的组织没有记录任何正在进行的项目的相关数据。57%的组织没有使用成本会计。80
3、%的项目在成本或时间上超出预算。超出成本和时间的项目里仅有50%的是有意义的超出。进行了成本估算的组织里，62%的组织是基于感觉和经验，仅仅16%的组织使用了正式的估算方法，如成本估算模型。,Software Estimation,Case Study,案例,Carl负责Gaga-safe公司库存控制系统1.0版本的开发（ICS），在参加项目监督委员会第一次会议的时候，他对期望的功能已经有了总体设想。Bill是监督委员会的领导，他问：“Carl，ICS1.0需要多长时间？”Carl回答：“大概要9个月，不过这只是粗略的估算。”“不行，”Bill说，“我真希望你说3或4个月，我们一定要在6个月内
4、拿出系统，能完成吗？”“我不能肯定，”Carl坦白地说，“我还得仔细研究一下，不过我相信可以找到办法在6个月内完成。”“那么把6个月当成项目完成的目标，”Bill说，“无论如何我们都必须这样做。”委员会的其他人一致同意了这个决定。到第五周的时候，又增加了一些产品概要设计工作，这使Carl更确信项目的时间更接近9个月而非6个月，然而他还是认为运气好的话有可能在6个月内完成项目。他不想被看作惹麻烦的人，所以决定等等再说。,凭直觉的项目估算,Software Estimation,Case Study,案例（续）,Carl的团队努力地工作着，进展稳定，但需求分析的时间比期望的要长。预定6个月要完成的
5、项目已经过去4个月了。“2个月无论如何也做不完剩下的工作。”他只好告诉Bill，项目需要延长2个月，总共需要8个月时间。几个星期后Carl意识到设计进度也不像期望的那么快。“先做容易的部分，”他告诉项目组成员，“其余的部分遇到时再考虑。”Carl再次向监督委员会汇报：“8个月的项目已经过去7个月，详细设计基本完成，工作卓有成效，但是8个月内还是无法完成。”Carl通报了第2次进度拖延，并将完成时间定为10个月。Bill对拖延产生了抱怨，并要求Carl想办法仍将进度安排在8个月左右。第9个月，项目组完成了详细设计，但部分模块的编码还没有开始。Carl第3次要求要求延期12个月。Bill?编码进行
6、顺利，但一些地方需要重新设计和重新实现，而这些地方项目组没有把详细设计调整好，一些实现过程相互冲突。在第11个月的项目监督委员会上，Carl宣布了第4次项目延期13个月。Bill？结果？,凭直觉的项目估算,Software Estimation,The Software-Estimation Story,软件估算与建筑预算,一年的时间建这样一幢房子？没问题！,太好了，那我们赶快开工吧！,软件与建筑,Software Estimation,The Software-Estimation Story,软件估算,软件开发是一个改进的过程,盖一幢房子要花多少钱呢？这取决于房子本身。一个新的计费系统要花
7、多少钱呢？这也取决于计费系统本身！一些组织希望在需求定义投入前就把成本估算的误差控制在10%以内，尽管项目估算的精确程度越早达到越好，但理论上是不可能实现的。如果真能那么早实现，精确度可以控制在2%以内。软件开发是一个逐步细化的过程，在每个阶段，都可能做出影响最终项目成本与进度的决策。,Software Estimation,The Software-Estimation Story,软件估算,可能细化的数量,估算收敛图,Software Estimation,The Software-Estimation Story,软件估算,可能细化的数量,基于项目阶段的估算误差系数,Software E
8、stimation,The Software-Estimation Story,软件估算,估算与控制,期望的功能与可用的资源 大多数软件项目在开始时，期望的功能与可用的资源之间不匹配，但随着项目的进展，功能或资源（或两者）必定要互相匹配,Software Estimation,The Software-Estimation Story,软件估算,合作,表达你合作的意愿,估算既不要过高也不要过低，应该正好与费用相符。估算的目标是寻找估算与实际情况的交汇点。,精确与准确：航班时刻通常精确到分，但不准确。可能的最短软件开发进度是通过建立最可能的准确估算而不是最精确的估算达到的。如果想获得最快的开发速
9、度，就要避免错误的精确。,Software Estimation,软件估算步骤,确定软件范围确定工作所需资源确定估算内容估算改进,Software Estimation,确定软件范围,确定软件估算范围，就是确定目标软件的数据和控制，功能，性能，约束，接口以及可靠性。,软件估算步骤,Software Estimation,确定工作所需资源,期望的功能与可用的资源 大多数软件项目在开始时，期望的功能与可用的资源之间不匹配，但随着项目的进展，功能或资源（或两者）必定要互相匹配,软件估算步骤,Software Estimation,确定工作所需资源,可重用软件资源可分为以下几种：,可直接复用的构件具有
10、完全经验的构件具有部分经验的构件,能够从第三方厂商获得或已经在以前的项目中使用过的软件，这些构件已经经过验证及确认，且可以直接用在当前的项目中。,、以前在类似项目中建立的规约，设计，代码或测试数据，在本项目中需做修改。,、以前在类似项目中建立的规约，设计，代码或测试数据，在本项目中需做实质上的修改。,软件估算步骤,Software Estimation,确定估算内容,规模估算工作量估算进度估算成本估算缺陷数估算,软件估算步骤,Software Estimation,规模估算,软件规模指的是非常普通意义上的软件总的范围。它包括功能集的深度和广度以及软件的难度和复杂性。规模估算方法有以下几种：,用
11、估算算法，如功能点方法，特征点，对象点，模糊逻辑，标准构件法，Delphi方法，PERT方法等。用规模估算软件。如果参与过类似的项目，并知道它的规模，那么按百分比形式估算新系统每个主要部分与旧系统相似部分的规模。每部分的规模加起来是总规模。,软件估算步骤,Software Estimation,工作量估算,对软件所需的工作时间的估算，通常以人时，人天，人月，人年等单位来衡量。工作量估算可以采用以下方法进行：,使用估算软件直接从规模估算得出使用组织中的历史数据确定具有已估算规模的先前的项目花了多少工作量。使用COCOMO模型或其他模型将代码行估算转换成工作量估算。采用Delphi方法，PERT方
12、法等直接进行工作量估算。,软件估算步骤,Software Estimation,进度估算,进度估算是针对以阶段为单位的估算，进度以不同阶段的里程碑作为标志，而不是对每一个细小任务都加以估算，对任务的适当分解很重要，分解的越细反而会不准确。进度估算可以采用以下方法进行：,采用经验法，或Delphi方法，PERT方法等直接进行工作量估算。使用组织中的历史数据。使用COCOMO算法或其他算法的进度估算步骤，提供一种更好的估算。基于承诺的进度表。即将任务分解后，由承担任务的项目组成员给出进度承诺，这种方法许多时候非常有效。,软件估算步骤,Software Estimation,进度估算方法,经验估算方
13、法,月进度=3.0*人月(1/3)例：65人月的工作量，进度=3.0*65(1/3)12个月5-6人（65/12）,3.0,4.0,2.5,Software Estimation,由功能点计算进度的幂次,这个准则不能取代更仔细的进度估算，但它提供了一个获得粗略进度估算的最简单方法。,Jones的一阶估算准则,Software Estimation,进度估算方法,成本估算,包括人力，设备，有形的，无形的支出成本估算，其中以人力与软硬件设备成本为主要部分。容易被忽视的是学习成本，培训成本，风险成本，维护成本等。人力成本主要基于工作量，进度估算。,软件估算步骤,Software Estimation
14、,缺陷数估算,包括需求，设计，代码中的缺陷，缺陷数影响项目的工作量，进度估算。通常以千行代码缺陷数等表示。缺陷数估算往往需要使用组织中的历史数据。,软件估算步骤,Software Estimation,软件估算方法,功能点估算（1984IBM方法）,输入输出查询内部逻辑文件外部接口文件,项目早期，需求说明书 面向数据库,Software Estimation,功能点估算（1984IBM方法）,按上表计算未调整的功能点总数 然后根据14个对程序有影响的因素计算“影响系数”，这些因素包括数据通信、联机数据条目、处理复杂性和安装容易度等。影响系数在0.65到1.35之间。,Software Esti
15、mation,软件估算方法,功能点估算（1984IBM方法）,计算功能点数的例子,Software Estimation,软件估算方法,Delphis Wideband方法,当许多专家基于相同假定独立地作出了相同估计，该估计多半是正确的必须确保专家针对相同的正确的假定进行工作,Software Estimation,软件估算方法,Delphis Wideband方法的步骤,1.识别做估计的群组-专家估计者(4-6项目经理)-作者-估计协调者2.作者呈述待作估计的系统3.作者和专家一起识别作业和假定4.作者和专家一起就可接收的估计差异水准达成一致(例如20%)5.协调者整理一份群组所决定的作业清
16、单，发给每个专家6.针对每个作业，专家独立地对每个作业作出估计（无讨论/咨询），将估计交给协调者7.协调者作出如下表格的综合：样表,Software Estimation,软件估算方法,Delphis Wideband方法的步骤,8.协调者将综合表发给全部专家和作者9.当%差别(variance)大于可接受水平时，专家与作者讨论作业和假定。不讨论估计值。某些作业可能作进一步分解或合并10.返回步骤5；继续工作直到全部作业处在可接受水平之内偏差率Max(最大值平均值),(平均值最小值)/平均值,Software Estimation,软件估算方法,Delphis Wideband方法的关键,绝对
17、不讨论估计。讨论作业和假定估计是保密的。估计者不知道相互的估计应至少有三个估计者将项目分解到小的作业（约20个人日）,Software Estimation,软件估算方法,PERT方法,Pert Sizing（Putnam Beta）方法是一种基于统计原理的估计方法，是一种简单易用、实效性强的软件估计方法。对于指定的估计单元（可能是规模、进度、工作量等），由直接负责人给出估计结果，估计结果由3个值构成：最小值、最大值、最可能值，通过计算公式：期望值=（最大规模+4*最可能规模+最小规模）/6 标准偏差=（最大规模-最小规模）/6 得到估计的结果。,Software Estimation,根据给
18、出的三个值，推算出来最有可能接近实际值的规模。,期望值-标准偏差，期望值+标准偏差 是一个可以接受的规模估计范围，如果你的最终实际值能够落到该范围内，则可以被认为你的估计是成功的。初期该范围可以较大，随着估计的不断精确，该范围应该逐渐被有意识的减少以求得更准确的估计。,建议：(最高-最低)/最可能 40,软件估算方法,PERT方法的应用,这种方法通常与WBS（任务分解）方法结合使用，可用于对于规模、进度、工作量的估计，通常用于规模估计，尤其适用于估计专家不足的情况。也可以和Delphi方法结合使用。,Software Estimation,软件估算方法,PERT方法的角色,Software E
19、stimation,软件估算方法,PERT方法的改进点,1、根据实际估计结果，给出项目的实际值与最低、最高估计值的差距。2、给出每模块实际值与最低、最高估计值的差距，计算准确估计的所占比率。3、在多个项目估计的基础上，修正最低和最高值的建议范围，趋势减小。4、收集项目估计过程中的问题，改进估计方法的每个步骤，并增加常见偏差指导。5、项目估计值和实际值以及分析作为经验数据保存到过程数据库，供以后参考。,Software Estimation,软件估算方法,将WBS、PERT、Delphi几种方法结合起来使用的示例,WBS是估算的基础，估算作业可以用WBS表给出，每个专家单独估算时采用PERT方法
20、，而整个估算采用Delphi估算。假定一个软件系统分为5个功能模块，我们请5个专家对项目的需求、设计、编码、测试工作的工作量进行估算，工作量的单位是人月。,Software Estimation,软件估算方法综合应用,将WBS、PERT、Delphi几种方法结合起来使用的示例,每个专家基于WBS、PERT方法单独进行估算的示例,Software Estimation,软件估算方法综合应用,将WBS、PERT、Delphi几种方法结合起来使用的示例,WBS、PERT、Delphi综合应用进行工作量估算的示例,Software Estimation,软件估算方法综合应用,估算的表达方式,加减限定范
21、围风险量化情况粗略的日期和时间段把握性因素,Software Estimation,加减限定范围风险量化情况粗略的日期和时间段把握性因素,Software Estimation,估算的表达方式,加减限定范围风险量化情况粗略的日期和时间段把握性因素,Software Estimation,估算的表达方式,加减限定范围风险量化情况粗略的日期和时间段把握性因素,Software Estimation,估算的表达方式,估算改进,单点估算例子,Software Estimation,范围估算例子,Software Estimation,估算改进,估算再修正的例子,假定有一个6个月的进度计划，计划4周完成
22、第一个里程碑，而实际用了5周。这时：假定能在后续进度中弥补损失的一周？把这一周加到整个进度中？把整个进度乘以拖延的数量（比例），本例中为25%？,Software Estimation,估算改进,软件估算的原则与技巧,估算时间越早，错误越大，但仍然要在项目初期就开始估算。估算的目的是用来做决策，而不是估算完成就完了。留出估算的时间，并做好计划。避免无准备的估算。估算文档化做得越好，获得估算经验的机会越大，这些经验可以为以后的项目估算提供参考使用以前项目的数据。使用以开发人员为基础的估算。进行详细的较低层次上的估算。不要忽略普通任务。走查估算。使用软件工具估算。使用几种不同的估算方法。估算的目的是得到准确的结果，不是寻求特定的结果。,Software Estimation,数据转换、安装、定制、B测试程序管理、向客户或用户演示程序、参加变更控制会议、项目进行中现有系统的维护与技术支持、缺陷修正、与SQA的协调、用户文档支持、技术文档评审、集成、休假、节假日、员工病假、公司和部门会议、培训等,项目组成员分别估算项目的各个部分，然后开一个走查会议比较所有的估算。充分讨论估算的差别并了解出现差别的原因，一直到估算范围的高低界限达成一致意见才算完成。,
