下载

1下载券

加入VIP
  • 专属下载特权
  • 现金文档折扣购买
  • VIP免费专区
  • 千万文档免费下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 软件工作量估算

软件工作量估算.ppt

软件工作量估算

517022409
2012-06-02 0人阅读 举报 0 0 暂无简介

简介:本文档为《软件工作量估算ppt》,可适用于高等教育领域

软件项目工作量估算软件项目工作量估算软件工作量估算软件工作量估算有些估算做得很仔细而有些却只是凭直觉的猜测。大多数项目超过估算进度的到%但也有少数一些组织的进度估算精确到了%以内能控制在%以内的还没有听说。Jones,软件工作量估算软件工作量估算“大多数IS人士无论是否为管理者从来都无权控制他们自己的进度计划。进度计划通常由市场部或高层管理部门直接下达就像飞石从天而降(也有人称之为鸟粪)”“就此问题我曾与IS领域中许多人士进行过交流。大家一致认为当前IS领域面临的最大难题既不是掌握快速更新的技术也不是探求新型的管理哲学而是被迫接受根本无法达到的进度计划。”(RobertLGlass)一个月的时间造这样一栋房子?没问题太好了那我们开工吧!你当初计划万元造的房屋可能最终的实际造价为万元。从造房子中学到的从造房子中学到的除非你确切知道“它”是什么?否则无法说明它的确切花费。盖房子时可以盖梦想中的房子(不考虑花费)也可以按估算盖但是功能必须具有一定的灵活性不确定性问题不确定性问题客户会要求X功能吗?客户要的是X功能的便宜版本还是昂贵版本呢?同一功能的不同版本的实施难度至少有%左右的差别。如果实施了X功能的便宜版本客户会不会以后又想要昂贵的版本。X功能如何设计?同一功能的不同设计在复杂度方面会有%左右的差别。X功能的质量级别是什么?依据实施过程的不同首次提交的X功能的缺陷数量会有%的差异。调试和纠正X功能实施过程中的错误要花多少时间?研究发现调试和纠正同样的错误不同程序员所花时间会有%左右的差异。把X功能和其它功能结合起来要花多少时间?……软件工作量估算的渐进性软件工作量估算的渐进性  估算的准确性和精确性估算的准确性和精确性准确(accuracy)是结果与目标之间有多近用代表圆周率比用更准确精确(precision)是结果有多少有意义的位数比代表圆周率更精确一个结果可以不准确而精确不精确而准确软件估算中错误的精确是准确的敌人~个人月的工作量估算可能是最准确又最精确的估算而精确到个人月看起来更精确但不准确。软件工作量估算困难的原因软件工作量估算困难的原因估算困难是由于软件的本质带来的特别是其复杂性和不可见性。软件开发是人力密集型工作的因而不能以机械的观点来看待传统的工程项目经常会议相近的项目做参考不同的只是客户和地点而绝大部分软件项目是独一无二的。新技术的不断出现和应用。缺少项目经验数据许多组织无法提供原有项目数据而即使提供了这些项目数据也未必非常有用。例子例子结论:很难用这些数据去估算项目工作量估算的其它困难工作量估算的其它困难某些人试图建立一个过去项目的全软件业的数据库但是许多词汇意义的不明确使得这种努力没有效果例如“测试”阶段究竟包括哪些活动就不明确。估计的主观性:人们容易低估小项目的工作量而过分夸大大项目的工作量估计的政治因素:不同的人有不同的目标如项目经理会高估项目工作量许多机构采用独立的估算小组但是将项目经理和项目成员吸收进估算小组能够增强他们的责任感。何时需要度量何时需要度量策略计划:选择合适的项目可行性分析系统描述:实现各个需求的工作量需要被衡量评估供应商的建议项目计划:项目进行过程中估算越来越准确在项目开始阶段考虑的是用户需求不考虑实现但是为了估算有时需要考虑一些实现方法过高估计和过低估计的问题过高估计和过低估计的问题过高估计的问题Parkinson法则:给的时间越多工作花费的时间也越多Brook法则:当人数增加后项目所需的工作量将不成比例的增加。当团队规模变大后由于管理协调和通信的增加将造成工作量的增加。因而“投入更多的人将使延期的工作更加延期”过低估计的问题质量降低Weinberg的可靠性零法则“如果系统不必可靠那么它可以满足任何目标”。工作量估算对职员的影响工作量估算对职员的影响如果职员能够完成目标那么他们将受到鼓舞如果他们发现目标根本不能完成那么他们的激情将受到极大损害因而估计不是一种简单的预测行为而是一种管理目标软件估算的基础()软件估算的基础()历史数据的需要在参考历史数据时需要考虑不同的环境如编程语言软件工具标准和人员的经验。工作度量直接计算真正的成本或时间是不可能的。编写程序的时间不同的人将有显著的区别。通常将工作量表达为如源代码的数量(sourcelineofcodeSLOC)或者千行代码量(KLOC)软件估算的基础()软件估算的基础()复杂性相同KLOC的两个程序花费的时间将会不同。因而不能简单地应用KLOC或SLOC而要根据复杂性进行修正但是复杂性的度量通常是主观而定的。基于承诺的估计基于承诺的估计一些组织直接从需求出发安排进度而不进行中间的工作量估算。他们要求每个开发者作出进度承诺而非进度估算。有利于开发者对进度的关注开发者在接受承诺后士气高昂自愿加班加点问题在于开发者的估算比现实要乐观大约低至个百分点(VanGenuchten,)承诺应该现实可行以使你的团队会不断成功而不是不断失败。软件工作量估计技术软件工作量估计技术自下而上:各个部分的工作量先估算出来然后进行合成自顶向下:首先定义整个项目的工作量然后分解到各个部分专家判断对比法算术模型Parkinson:能够使用的参与该项目的人力赢利价格:赢得合同的价格自底向上方法自底向上方法该方法首先将项目分成部件任务然后估算每个任务所需的工作量。在大型的项目中分解任务的过程是一个叠代的过程直到最下面的任务不可分解产生WBS。该方法适合于项目规划的后期。如果应用在前期那么必须对最终的系统作出一些假设例如对软件模块的数量和大小进行假设。如果项目是全新的或者没有历史数据建议用该方法练习练习工资系统已经被安装在某学院目前有一个新的需求需要在系统中添加一个子系统该系统分析每节课时老师的成本。每个老师的工资可以从系统中获得每个老师花在每个课程上的时间也可以从系统中获得。为了实现该系统需要哪些任务哪些任务的工作量比较难计算。练习练习答案获取用户需求分析系统中已有数据设计报表和编写用户建议编写测试计划编写技术描述设计软件写软件测试软件写说明书执行接受测试设计写测试软件将最难估算工作量自顶向下方法自顶向下方法自顶向下的方法和参数化模型一般采用对比方法确定总的工作量对比是建立在一系列参数的基础上的通过这些参数可以计算出新系统的工作量形式:effort=(系统规模)*(生产率)例如系统规模可以用KLOC来计算生产率以天KLOC预测软件开发工作量的模型有两个部分第一部分为估算软件大小第二部分为估算工作效率练习练习学生要求每学期写一篇有关IT的报告如果你想建立一个估算学生完成这样一份报告的模型你用什么来衡量报告的大小什么因素会影响学生完成报告的难度?字数材料能否获取对主题的熟悉程度宽度深度技术难度专家判断专家判断具有应用领域或者开发环境知识的人员对任务的评估该方法特别是在对原有系统进行替换时有用评估者对影响的代码的比例进行分析从而得到工作量评估。类比估计类比估计类比方法又被称为基于案例的推理(Casebasedreasoning)评估者寻找已经完成的项目这些项目与需要开发的新项目在许多特征上必须是类似的。如何选择与待预测的项目相近的项目?欧几里的距离(EuclideanDistance)公式distance=((目标系统参数原系统参数)(目标系统参数原系统参数)……)的平方根练习练习假定将要构造的系统有个输入个输出过去有一个项目有个输入个输出这两个项目的是多少?答案:Albrecht功能点分析Albrecht功能点分析该方法是由AllanAlbrecht在IBM工作时发明的自顶向下方法。功能点法(FunctionPoints)的基本点是计算机信息系统包括五个主要部件或者外部用户类型它们是:外部输入:应用数据外部输出:提供给用户的面向应用的信息内部逻辑文件:逻辑主文件外部接口文件:与其它系统交换信息外部查询:在线的输入以获得立即的结果功能点方法功能点方法加权因子的确定练习练习在学院工资系统项目中需要开发一个程序该程序将从会计系统中提取每年的工资额并从两个文件中分别提取课程情况和每个老师教的每一门课的时间该程序将计算每一门课的老师的成本并将结果存成一个文件该文件可以输出给会计系统同时该程序也将产生一个报表以显示对于每一门课每个老师教学的时间和这些工时的成本。假定报表是具有高度复杂性的其它具有一般复杂性练习练习外部输入:无外部输出:报告内部逻辑文件:财务输入文件外部接口文件:工资文件人员文件课程文件财务输入文件外部查询:无考虑加权:外部输入:无外部输出:×=内部逻辑文件:×=外部接口文件:×=外部查询:无共:功能点方法:复杂性判定功能点方法:复杂性判定如何判定功能的复杂性?国际功能点用户小组(IFPUG)内部逻辑文件、外部接口文件外部输入文件功能点方法:复杂性判定功能点方法:复杂性判定外部输出文件如何确定记录个数和数据个数如某系统内部逻辑文件:订单文件包含订单信息(包括订单号供应商名称订单日期)和订单项(包括商品号价格和数目)则记录个数为数据个数为在表中可以确定该功能点复杂性为低。功能点方法:转换为代码行功能点方法:转换为代码行通过定义各个功能点对应各种语言的代码行数则功能点可以转化为代码行一些数据:Cobol:C:QuickBasic:ObjectOrientedLanguages:MarkII功能点MarkII功能点该方法被作为英国政府项目实施中采用的标准基本原理:对于一个处理事务计算方法:wi×输入数据元素+we×实体+wo×输出数据元素系数总和为标准设置为,,MarkII功能点MarkII功能点系数调整考虑因素:与其它应用的接口特殊的安全特征与第三方的直接交互用户训练特征文档需求功能点的其它扩展功能点的其它扩展功能点方法起源于业务信息系统应用因而强调了数据方面的因素而没有考虑功能和行为(控制)方面的因素。特征点(FeaturePoints):除了考虑普通功能点的内容外还考虑了算法的特征(矩阵转换字符串解析处理中断等都是算法的例子)Boeing提出了一个三维功能点方法(D)其中三维为数据维功能维(输入转化为输出的步骤)和控制维(状态之间的转换数)。功能点转化为工作量功能点转化为工作量对于原来的项目计算生产率:生产率=功能点数目工作量(人日)则对于新项目功能点计算出来后工作量为:工作量=功能点数目生产率更复杂的方法:最小二乘法即工作量=系数+功能点数×系数对象点对象点ObjectPoints起源于纽约大学的LeonardNStern商学院它类似于功能点方法但是更容易计算。对象点方法与面向对象方法并无直接联系。该方法计算应用所需要处理的屏幕报告和部件这些都被称为对象。每一对象需要被确定为简单的中等的困难的三个层次。对象点方法对象点方法对象点转换为工作量对象点转换为工作量首先考虑已经存在的对象应该排除在工作量计算内。即计算新的对象点(NOP)根据原来从事过的项目计算在不同情况下的项目的生产率例如下表:假定有个对象点要开发开发者的经验和工具使用都是一般性的则需要=个月大致进度估算方法大致进度估算方法大致的(Bullpark)进度估算软件估算方程和系数一定程度上比较难掌握软件工作量估算软件比较昂贵大致的估算简单宜行三个进度表可能的最短进度有效的进度普通进度可能的最短进度可能的最短进度非常乐观的假设(员工%顶尖人才管理工具方法)两个事实:存在一个最短的进度而且不可能突破一个人天内能写出行程序个人一天内能完成吗?个人小时内能完成吗?当你把进度缩短得比普通进度短时费用将迅速上涨。有效进度可能得最短进度费用交付时间有效进度与普通进度有效进度与普通进度有效进度假定人才:顶尖的前%的人才人员调整每年小于%可能的最短进度与有效进度的关系进度变长了但是工作量也许减少了压缩进度是要付出代价的普通进度估算修正估算修正经理和客户常问的一个问题“如果我给你额外一个星期做估算你能修正它以减少不确定性吗?”答应这种要求最后将给自己带来麻烦因为减少不确定性必须在软件开发过程本身中进行。许多项目中要求给出单点估计这种方法的结果是估算永远不准确理智的方法是先给出大的区间逐步缩小区间。估算的再修正估算的再修正假定有一个个月的进度计划计划周内达到第一个里程碑而实际上花了周如何修正进度:在后续进度中弥补损失的一周把这一周加到进度中整个进度乘以拖延的数量本例乘以%估算的再修正估算的再修正年对多个项目的调查表明项目几乎不能弥补损失的时间(VanGenuchten,)第一阶段估算不准确的原因一般会分布在整个项目中估算的技巧估算的技巧避免无准备的估算不要随口说出一个估算留出估算的时间并做好计划估算本身也是一个项目开发人员参与估算不要忽略普通任务使用几种不同的估算技术并比较它们的结果估算的群体讨论过于乐观的进度计划过于乐观的进度计划MicrosoftWordforWindows开发包含行代码投入人月前后历时年实际花费时间为预期时间的倍过于乐观的进度计划过于乐观的进度计划导致WinWord开发延迟的几个主要因素:项目初期制定的开发目标是不可实现的。盖茨下达的指示是用最快的速度开发最好的字处理软件争取在月内完成。实现这两个目标中的任何一个都是困难的同时达到则是不可能的。过紧的进度计划降低了计划的精确度。开发过程中频繁换人。年中共换了个组长其中有人因进度压力离职人是出于健康的原因而离职。迫于进度压力开发人员匆忙写出一些低质量的和不完整的代码然后宣称已实现某些性能。这造成了WinWord不得不将用于提高软件稳定性的时间由预计的个月增加到个月。由于该项目中创新比速度更重要因而试图缩短开发周期反而使周期变长产生过于乐观的进度计划的根源产生过于乐观的进度计划的根源为了赶在某些特定时间前展示或出售产品。如计算机交易展示会。管理人员和客户拒绝接受仅给出范围的估算而是按照他们认为的“最佳”估算来制定进度计划。项目管理人员和开发人员为了享受挑战的乐趣或在压力下工作的刺激而故意缩短进度计划。管理部门和市场部门为了迎合客户而缩短进度计划。项目管理人员认为较紧的进度计划能够使员工勤奋工作。原先的估计是合理的但是在项目进行过程中又加进了很多新特性从而变成了过于乐观的进度。……过于乐观的进度计划的后果过于乐观的进度计划的后果进度计划准确性过于乐观的进度计划的后果过于乐观的进度计划的后果计划的质量:错误的假设必将导致无效的项目规划。抛弃计划:当面临进度压力时大多数开发组织会抛弃原有规划而走入盲目开发的歧途。如果试图在关键阶段节省时间必将在后续阶段加倍补偿。分散了管理者的注意力:管理者将分散经历在不断调整计划上。客户关系:项目一拖再拖客户将失去耐心。过于乐观的进度计划的后果过于乐观的进度计划的后果仓卒收尾要排错只能将系统拆分后再进行一个小的变动要花很长时间。开发人员清楚地知道系统中存在一些应作修改却未做的地方。测试人员发现错误的速度大于开发人员排错的速度。排除已发现错误的同时产生了大量新的错误。由于软件变化频繁难以保证用户文档的同步更新。项目估算多次调整软件交付日期一拖再拖。超负荷的进度压力超负荷的进度压力产品质量的降低赌博心理导致风险管理的忽略激励效应不再起作用创造性思维受损精疲力竭:在后面的项目中难以提起热情中途退出:这些人通常是有能力的人长期地进行快速开发:难以补充新知识开发人员与管理人员的关系:不切实际的进度压力会使开发人员丧失对管理人员的尊重。有原则的谈判有原则的谈判该谈判的策略的中心是致力于探求一种双赢的解决方案。将人从困境中解脱站在他人的立场上加以考虑(各人有各人的烦恼)以合作的态度来努力改善与管理人员和客户的关系制定比较现实的进度估算尽量使各方都能理解进度估算的意义。不要针锋相对有原则的谈判有原则的谈判关注共同利益不要过分坚持立场有时候必须作出让步可以从下列几个方面加以说服:真正提高开发速度增加成功的机会引用以前类似项目的失败教训有原则的谈判有原则的谈判提出多种备选方案、与产品有关的灵活变通:将一些设计功能放到下一版本实现大多数人在提出需求时并不清楚这些需求是否必须全部在当前版本被满足。分阶段交付产品。如版本,,每版实现最迫切的功能。砍去某些实现起来费时或者需要谈判后才能确定的特性包括与其它系统的整合能力。与旧版本兼容的能力以及产品性能等。对某些特性不必精雕细琢只需实现到某种程度即可。尽量轻松地实现各特性地详细功能需求。可以通过一些商业组件来实现。有原则的谈判有原则的谈判与项目资源有关的灵活变通如果处于项目初期则增加更多的开发人员增加高层次的开放人员(如领域专家)增加更多的测试人员在管理方面给予更多的支持提高开发的支持力度如更安静更独立的工作间速度更快的计算机技术人员随时维护环境提高最终用户的参与度最好在项目组中配备一个能够对特性设置最终拍板的用户提高主管人员的参与度有原则的谈判有原则的谈判与进度计划有关的灵活变通在详细设计产品设计或至少是需求分析完成之前只提出一个进度目标但不设定一个确切期限如果是在项目初期则在提炼产品概念功能要求合详细设计时可以探求缩短开发时间的方法先给出进度估算范围或大概的进度估算值然后随着项目的进展逐步精确其他为开发人员提供额外的支持以保证他们能集中精力于项目的开发例如购物服务供餐洗衣清洗住所等采取更多的激励措施如休假旅游加班工资等有原则的谈判有原则的谈判坚持客观标准只能向原则低头而不能向压力屈服谈判不要局限于估算本身即可以考虑项目的输入条件有条件的话可以由专业估算机构进行估算坚持科学的估算过程顶住压力

用户评价(0)

关闭

新课改视野下建构高中语文教学实验成果报告(32KB)

抱歉,积分不足下载失败,请稍后再试!

提示

试读已结束,如需要继续阅读或者下载,敬请购买!

文档小程序码

使用微信“扫一扫”扫码寻找文档

1

打开微信

2

扫描小程序码

3

发布寻找信息

4

等待寻找结果

我知道了
评分:

/62

软件工作量估算

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利