ch05-工作量估算PPT格式课件下载.ppt

ch05-工作量估算PPT格式课件下载.ppt

《ch05-工作量估算PPT格式课件下载.ppt》由会员分享，可在线阅读，更多相关《ch05-工作量估算PPT格式课件下载.ppt（63页珍藏版）》请在冰点文库上搜索。

软件估算中错误的精确是准确的敌人40-70个人月的工作量估算可能是最准确而又最精确的估算，而精确到55人月看起来更精确，但不准确。

软件工作量估算困难,估算困难是由于软件的本质带来的，特别是其复杂性和不可见性。

软件开发是人力密集型的工作，因而不能以机械的观点来看待。

传统的工程项目经常会以相近的项目做参考，不同的只是客户和地点，而绝大部分软件项目是独一无二的。

缺少项目经验的数据，许多组织无法提供原有项目的数据，而即使提供了这些数据，也未必非常有用。

工作量估算的其它困难,某些人试图建立一个过去项目的全软件业的数据库，但是许多词汇意义的不明确使得这种努力没有效果，例如“测试”阶段究竟包含哪些活动就不明确。

估计的主观性：

人们容易低估小项目的工作量，而过分夸大大项目的工作量。

估计的角色因素：

不同的人有不同的目标，如项目经理会高估项目的工作量。

许多机构采用独立的估算小组，但是将项目经理和项目成员吸收进估算小组，能够增强他们的责任感。

在何处进行估计？

策略计划：

选择合适的项目可行性分析：

系统需求分析：

实现各个需求的工作量需要被衡量。

评估供应商的建议项目计划：

项目进行过程中，估算越来越准确（估算的渐进性）在项目的开始阶段考虑的是用户的需求，不考虑实现，但是为了估算，有时需要考虑一些实现的方法。

过高估计和过低估计的问题,过高估计的问题Parkingson法则：

给的时间越多，工作花费的时间越多。

Brooks法则：

当人数增加后，项目所需的工作量将不成比例的增加。

当团队规模变大以后，由于管理、协调和通信的增加，将造成工作量的增加。

因而，“投入更多的人将使延期的项目更加延期”过低估计的问题质量降低Weinberg的可靠性零法则：

如果系统不必可靠，那么它可以满足任何目标。

工作量估算对员工的影响,如果职员能够完成目标，那么他们将受到鼓舞如果他们发现目标根本不能完成，那么他们的激情将受到极大的损害如果软件开发成本估算误差在该项目工作估算理想成本估算的20以内，那么优秀的经理就能将其变成自我实现的预言！

BarryBohem因而，估计不是一个简单的预测行为，而是一种管理的目标。

工作量估计不仅仅是技术问题,软件估算的基础

（1）,历史数据的需要在参考历史数据的时候需要考虑不同的环境，如编程语言、软件工具、标准和人员的经验。

工作的度量直接计算真正的成本或时间是不可能的。

编写程序的时间不同的人将有显著的区别。

通常将工作量表达为源代码的数量（sourcelineofcode,SLOC）或者千行代码量（KLOC）复杂性：

递归程序Vs.图形用户界面,基于承诺的估计,一些组织直接从需求出发，安排进度而不进行中间的工作量估计。

他们要求每个开发者做出进度承诺而非进度估计。

有利于开发者对进度的关注，开发者在接受承诺后士气高涨，自愿加班加点。

问题在于开发者的估算比较乐观，大约低估20%30%（VanCenuchten，1991）承诺应该现实可行，以使你的团队不断成功而不是不断失败。

软件工作量估计的方法,软件工作量估算的方法自底向上的方法自顶向下的方法差别估算法,自底向上方法,该方法首先将项目分成部件任务，然后估算每个任务所需的工作量.在大型的项目中，分解任务的过程是一个迭代的过程，直到最下面的任务不可分解，产生WBS。

该方法适合于项目规划的后期。

如果应用在前期，那么必须对最终系统作出一些假设，例如对软件模块的数量和大小进行假设。

如果项目是全新的或者没有历史数据，建议用该方法。

练习,工资系统已经被安装在Brightmouth学院，目前有一个新的需求，需要在系统中添加一个子系统，该系统分析每节课时老师的成本。

每个老师的工资可以从系统中获得，每个老师的在每个课程上的时间也可以从系统中获得。

为了实现该系统，需要哪些任务，哪些任务的工作量比较难计算。

可能的活动包括：

获取用户的需求分析系统中已有的数据结构设计报表和编写用户建议书编写测试计划编写软件规格说明书编写软件测试软件编写操作说明书执行验收测试最难估计的任务通常是对要产生软件的规模和复杂程度最有影响的活动：

设计、编码和测试。

由于上述原因，软件规格说明书的编写也比较困难,自顶向下方法,自顶向下方法和参数化模型一般采用对比方法确定总的工作量对比是建立在一系列参数的基础上，通过这些参数可以计算出新系统的工作量。

形式工作量=系统规模生产率例如系统规模可以用KLOC来计算，生产率以40天/KLOC预测软件开发工作量的模型有两个部分，第一部分为估算软件大小，第二部分为估算工作效率,差别估算方法,将待开发项目与过去已完成项目相比较，通过估算每个不同之处对项目成本的影响，导出项目的总成本。

软件工作量估算的技术,软件工作量估算的技术专家判断类比估计算法模型Parkinson：

能够使用的参与该项目的人力赢利价格：

赢得合同的价格（成本的预算依靠预算而不是软件功能）,专家判断,具有应用领域或者开发环境知识的人员对任务的评估该方法特别是在对原有系统进行替换时有用。

评估者对影响的代码的比例进行分析，从而得到工作量的估算。

专家估算法-Delphi,组织者发给每位专家一份软件系统的规格说明和一张记录估算值的表格，请他们估算专家详细研究软件规格说明后，对该软件提出3个规模的估算值最小ai最可能的mi最大bi组织者对专家的表格中的答复进行整理计算每位专家的Ei=（ai+4mi+bi）/6,专家估算法-Delphi（续）,综合结果后:

E=E1+E2+En/n（N:

表示N个专家）比较估算差，并查找原因如果各个专家的估算差异超出规定的范围（例如：

15%），则需重复上述过程，最终可以获得一个多数专家共识的软件规模,专家估算法-举例,某多媒体信息查询系统专家估算专家1：

189=（1+9+4*8）/6=7（万元）专家2：

468=（4+8+4*6）/6=6（万元）估算结果=（6+7）/2=6.5（万元）,类比估计,类比方法又称为基于案例的推理（Case-basedreasoning）评估者寻找已经完成的项目，这些项目与需要开发的新项目在许多特征上必须是类似的。

如何选择与待预测的项目相近似的项目？

欧几里德距离（Euclideandistance）,假定将要构造的系统有7个输入，15个输出。

过去有两个项目。

项目A有8个输入，17个输出项目B有5个输入，10个输出。

项目B是否比项目A更类似于目标项目？

项目A与目标项目更类似。

Albrecht功能点分析,该方法是AllanAlbrecht在IBM工作时发明的自顶向下方法。

目标：

得到一个客观的软件规模的度量方法,功能点分析的基础是基于计算机信息系统由五个主要部件构成，在Albrecht的术语中由五个使用户受益的外部用户类型组成：

外部输入（EI）：

更新内部逻辑文件的事务。

外部输出（EO）：

输出数据给用户的事务。

这里的输出是指报表、屏幕信息、错误提示等等，报表中的各个数据项不再分别计数。

内部逻辑文件（ILF）：

系统使用的固定文件。

所谓的逻辑文件，是指逻辑上的一组数据组合。

它们可以是数据库的一部分，也可以是一个单独的文件。

外部查询（EQ）：

引发系统以联机方式产生某种即时响应的事务，不更新内部文件。

外部接口（EIF）：

与其他系统交换信息。

功能点计算,练习,在学院工资系统中需要开发一个程序，该程序将从工资文件中提取出每年的工资额，并从计时表系统中分别提取课程情况和每个老师教的每一门课的时间，该程序将计算每一门课程老师的成本并将结果保存成一个由总会计系统读取的一个文件中。

同时该程序也将产生一个报表，以显示对于每一门课，每个老师教学的课时数以及这些课时相应的成本。

假定报表具有高度复杂性，其他具有一般复杂性。

计算这个子系统的Albrecht功能点数。

外部输入：

0外部输出：

报告，1内部逻辑文件：

会计加载文件，1外部接口文件：

工资文件，人员文件（计时表），课程文件（计时表），3外部查询文件：

无考虑加权：

外部输入：

无；

外部输出17=7；

内部逻辑文件：

1110=10；

外部接口文件37=21；

外部查询：

共38,功能点方法：

复杂性判定,如何判定功能的复杂性？

国际功能点小组（IFPUG）内部逻辑文件，外部接口文件,外部输出文件外部输入文件外部查询按照EO和EI进行计算，取最大值,如何确定记录个数和数据个数？

如果某系统内部逻辑文件：

订单文件，包含订单信息（包括订单号，供应商名称，订单日期）和订单项（包括商品号，价格和数目），则记录个数为2，数据个数为6，在表中可确定该功能点复杂性为低。

考虑系统运行的环境,到目前为止，功能点分析还只考虑了系统功能以及功能的复杂度。

如何考虑系统运行的环境？

难度校正系数Fi：

其中，“总计数值”是原始功能点数；

Fi是按照表计算出来的系统难度系数。

i的取值从114。

计算项目功能点数的难度校正系数值,计算项目功能点数的难度校正系数值,计算项目功能点数的难度校正系数值,功能点方法：

转换为代码行,通过定义各个功能点对应各种语言的代码行数，则功能点可以转换为代码行：

一些数据：

功能点转化为工作量,对于原来的项目，计算生产率生产率=功能点/工作量（人日）则，对于新项目，功能点计算出来后，工作量为：

工作量=功能点数/生产率更复杂的方法：

最小二乘法工作量=系数1+功能点数系数2,COCOMO：

回归模型,COCOMO：

ConstructiveCostModel构造性成本模型目前最广泛使用、充分文档化并得到系统校准的估算模型回归模型：

从历史数据的统计解释而导出，以说明变量之间的平均或者“典型”的关系。

BarryW.Boehm在二十世纪70年代在TRW公司工作时，用基于回归的方法开发了COCOMO模型。

分析不同类型的63个项目，观察了项目实际LOC，实际工作量以及实际时间，然后使用回归分析来开发指数方程，最佳地描述了分散数据点之间的关系。

63个项目中只有7个是商务系统，因而它们不仅仅能被用于信息系统。

COCOMO系统,C,k的取值根据系统的分类而定：

根据系统的技术特征和开发环境可以分为：

有机模式（organicmode）：

相对较小较简单的软件项目（KDSI50）。

需求不很苛刻，开发人员对软件产品开发目标理解充分，软件工作经验丰富，对软件使用环境熟悉，受硬件约束小。

多数应用软件均属此类。

嵌入式模式（Embeddedmode）：

要求在紧密联系的硬件、软件和操作的限制条件下运行。

通常与某些硬设备紧密结合，因此对算法、数据结构、接口要求较高的软件规模任意。

例如大型OS软件、大型指挥系统软件等都属此类。

半分离模式（Semi-detachedmode）：

要求介于以上两种之间的软件。

规模、复杂性规模都在中等以上。

KDSI可能在300以上。

例如大型ERP、简单的指挥系统、大型事务处理软件等属于此类。

COCOMO,基本公式：

在COCOMO模型中，使用的基本量包括：

源指令行数：

DSI，度量单位为行或千行，1KDSI=1024DSI（不包括注释行）。

开发工作量：

MM，度量单位为“人月”，1MM=19人日=152人时=1/12人年。

开发进度：

TDEV，度量单位为月，它由工作量确定。

K的值反映了项目越大，工作量呈指数增加，因为大项目需要更多的协调和安排。

COCOMO修正,事实上，基本COCOMO模型对工作量的衡量不稳定，Boehm本人也发现了此问题，因而提出名义成本估算的问题。

首先从基本模型得到名义成本，然后采用开发成本乘法算子（developmenteffortmultiplier,dem）进行修正，即：

COCOMO81中级成本驱动因子,Dem的计算15个成本驱动因子,练习,在IOE中，绝大多待开发系统在技术上，产品、计算机和项目等属性都是类似的。

只有人员的属性有所差异。

Amanda经过考察认为：

分析员非常优秀，编程员也很优秀，但是对该项目面向的领域不熟悉并准备新的编程语言。

它们对操作系统很熟悉。

请计算dem。

如果名义工作量是4人月，则估算的工作量是多少？

Dem=0.711.130.800.901.07=0.62最后的估计40.622.48人月,大致进度估算方法,大致的（Ballpark）进度估算软件估算方程和系数一定程度上表难掌握软件工作量估算软件比较昂贵大致的估算简单易行三个进度表可能的最短进度有效的进度普通的进度,可能的最短进度,非常乐观的假设（员工10%顶尖人才，管理，工具，方法）两个事实存在一个最短的进度，而且不可能突破一个人5天能写出1000行程序，5个人一天能完成吗？

40个人一小时能完成吗？

当你把进度缩短得比普通进度短时，费用将迅速上涨。

软件开发项目最短时间下限速查表,进度压缩的费用,CharlesSymons91进度压缩因子=期望速度/初始速度压缩进度工作量=初始工作量/进度压缩因子练习：

项目初始速度为12个月，现要求在10个月内完成该工作。

假设初始工作量为78人月，估算相应工作量。

进度压缩因子=10/12=0.83压缩进度工作量=78/0.83=94进度压缩17%，工作量增加21%如果压缩到9个月?

进度压缩25%,工作量增加33%!

大多数研究人员已经得出结论，不可能获得低于0.75或0.80的进度压缩因子（Boehm1981;

PutmanandMyers1992;

Jones1994）。

这意味着，对于通过增加人员和要求加班加点来缩短进度，存在一个限制范围，这个范围最大也不过是25%。

如果你的压缩因子低于0.75，你就需要减少工作量或延长进度，而不是仅仅依赖进度压缩。

有效进度与普通进度,有效进度假定人才：

顶尖的25%的人才人员调整每年小于6%可能的最短进度与有效进度的关系：

项目比可能的最短进度表描述的项目花的全部工作量要少。

进度变长了，但是工作量也许也减少了压缩进度是要付出代价的,普通进度假定中等以上的人才；

项目组一般成员对编程语言和环境熟悉，但不必非常熟悉。

团队平均起来在应用领域还是有经验的，同样经验也不必特别丰富。

这些团队不是很有凝聚力，但在解决冲突上有一定经验。

他们经历过每年1O%到12%的人员调整。

编程工具和现代编程思想在一定程度上使用，但不像有效开发项日中使用得那么频繁。

如果你不确定是用有效进度还是普通进度，该怎么办呢?

如果大部分工作按照有效开发准则工作的话，采用有效进度；

如果项目在开发基础上比较薄弱，那么采用普通迸度。

具体参照快速软件开发,练习,假定有一个6个月的进度计划，计划4周内到达到第一个里程碑，而实际上花了5周，如何修正进度？

在后续进度中弥补一周的损失把这一周加入到进度中整个进度乘以拖延的数量，本例乘以125%,1991年对300多个项目的调查表明，项目基本不可能弥补损失的时间（VanGenuchten，1991）第一阶段估算不准确的原因一般会分布在整个项目中。

（比如人员，技术）,估算的技巧,避免无准备的估算不要随口说出一个估算留出估算的时间，并做好计划估算本身也是一个项目开发人员参与估算不要忽略普通任务使用几种不同的估算技术，并比较它们的结果估算的群体讨论,估算方法总结,估算实际上是管理的目标尽可能多的收集先前项目的信息使用两种以上的方法进行估计自顶向下方法用在项目的早期，而自底向上方法更多的用在后期使用他人的历史生产率数据作为估算基础时要小心，特别是来自不同环境的历史数据,