《讲座6软件项目工作量估算ppt课件.ppt》由会员分享，可在线阅读，更多相关《讲座6软件项目工作量估算ppt课件.ppt（76页珍藏版）》请在三一办公上搜索。
1、1,讲座6 软件项目工作量估算,2,软件工作量估算,有些估算做得很仔细，而有些却只是凭直觉的猜测。大多数项目超过估算进度的25%到100，但也有少数一些组织的进度估算精确到了10以内，能控制在5以内的还没有听说。Jones,1994,3,软件工作量估算,“大多数IS人士，无论是否为管理者，从来都无权控制他们自己的进度计划。进度计划通常由市场部或高层管理部门直接下达，就像飞石从天而降（也有人称之为鸟粪）”“就此问题，我曾与IS领域中许多人士进行过交流。大家一致认为当前IS领域面临的最大难题，既不是掌握快速更新的技术，也不是探求新型的管理哲学，而是被迫接受根本无法达到的进度计划。”（Robert.
2、L.Glass),4,一个月的时间造这样一栋房子？没问题,太好了，那我们开工吧！,你当初计划10万元造的房屋可能最终的实际造价为50万元。,5,从造房子中学到的,除非你确切知道“它”是什么？否则无法说明它的确切花费。盖房子时，可以盖梦想中的房子（不考虑花费），也可以按估算盖，但是功能必须具有一定的灵活性,6,不确定性问题,客户会要求X功能吗？客户要的是X功能的便宜版本还是昂贵版本呢？同一功能的不同版本的实施难度至少有10左右的差别。如果实施了X功能的便宜版本，客户会不会以后又想要昂贵的版本。X功能如何设计？同一功能的不同设计，在复杂度方面会有10左右的差别。X功能的质量级别是什么？依据实施过程
3、的不同，首次提交的X功能的缺陷数量会有10的差异。调试和纠正X功能实施过程中的错误要花多少时间？研究发现调试和纠正同样的错误，不同程序员所花时间会有10左右的差异。把X功能和其它功能结合起来要花多少时间？,7,软件工作量估算的渐进性,8,估算的准确性和精确性,准确（accuracy）是结果与目标之间有多近，用3代表圆周率比用4更准确精确（precision）是结果有多少有意义的位数，3.14比3代表圆周率更精确一个结果可以不准确而精确，不精确而准确，软件估算中错误的精确是准确的敌人，4070个人月的工作量估算可能是最准确又最精确的估算，而精确到55个人月看起来更精确，但不准确。,9,软件工作量
4、估算困难的原因,估算困难是由于软件的本质带来的，特别是其复杂性和不可见性。软件开发是人力密集型工作的，因而不能以机械的观点来看待传统的工程项目经常会议相近的项目做参考，不同的只是客户和地点，而绝大部分软件项目是独一无二的。新技术的不断出现和应用。缺少项目经验数据，许多组织无法提供原有项目数据，而即使提供了这些项目数据，也未必非常有用。,10,例子,结论：很难用这些数据去估算项目,11,工作量估算的其它困难,某些人试图建立一个过去项目的全软件业的数据库，但是许多词汇意义的不明确使得这种努力没有效果，例如“测试”阶段究竟包括哪些活动就不明确。估计的主观性：人们容易低估小项目的工作量，而过分夸大大项
5、目的工作量估计的政治因素：不同的人有不同的目标，如项目经理会高估项目工作量，许多机构采用独立的估算小组，但是将项目经理和项目成员吸收进估算小组，能够增强他们的责任感。,12,何时需要度量/,策略计划：选择合适的项目可行性分析系统描述：实现各个需求的工作量需要被衡量评估供应商的建议项目计划：项目进行过程中，估算越来越准确在项目开始阶段考虑的是用户需求，不考虑实现，但是为了估算，有时需要考虑一些实现方法,13,过高估计和过低估计的问题,过高估计的问题Parkinson法则：给的时间越多，工作花费的时间也越多Brook法则：当人数增加后，项目所需的工作量 将不成比例的增加。当团队规模变大后，由于管理
6、，协调和通信的增加，将造成工作量的增加。因而“投入更多的人将使延期的工作更加延期”过低估计的问题质量降低Weinberg的可靠性零法则“如果系统不必可靠，那么它可以满足任何目标”。,14,工作量估算对职员的影响,如果职员能够完成目标，那么他们将受到鼓舞如果他们发现目标根本不能完成，那么他们的激情将受到极大损害因而，估计不是一种简单的预测行为，而是一种管理目标,15,软件估算的基础（1）,历史数据的需要在参考历史数据时需要考虑不同的环境，如编程语言，软件工具，标准和人员的经验。工作度量直接计算真正的成本或时间是不可能的。编写程序的时间不同的人将有显著的区别。通常将工作量表达为工作量，如源代码的数
7、量（source line of code，SLOC），或者千行代码量（KLOC）,16,软件估算的基础（2）,复杂性相同KLOC的两个程序花费的时间将会不同。因而不能简单地应用KLOC或SLOC，而要根据复杂性进行修正，但是复杂性的度量通常是主观而定的。,17,基于承诺的估计,一些组织直接从需求出发安排进度而不进行中间的工作量估算。他们要求每个开发者作出进度承诺而非进度估算。有利于开发者对进度的关注，开发者在接受承诺后士气高昂，自愿加班加点问题在于开发者的估算比现实要乐观，大约低20至30个百分点（Van Genuchten,1991)承诺应该现实可行，以使你的团队会不断成功而不是不断失败。
8、,18,软件工作量估计技术,算术模型专家判断对比法Parkinson：能够使用的参与该项目的人力赢利价格：赢得合同的价格自顶向下：首先定义整个项目的工作量，然后分解到各个部分自下而上：各个部分的工作量先估算出来，然后进行合成,19,自底向上方法,该方法首先将项目分成部件任务，然后估算每个任务所需的工作量。在大型的项目中，分解任务的过程是一个叠代的过程，直到最下面的任务不可分解，产生WBS。该方法适合于项目规划的后期。如果应用在前期，那么必须对最终的系统作出一些假设，例如对软件模块的数量和大小进行假设。如果项目是全新的或者没有历史数据，建议用该方法,20,练习,工资系统已经被安装在Brightm
9、outh学院，目前有一个新的需求，需要在系统中添加一个子系统，该系统分析每节课时老师的成本。每个老师的工资可以从系统中获得，每个老师花在每个课程上的时间也可以从系统中获得。为了实现该系统，需要哪些任务，哪些任务的工作量比较难计算。,21,练习,答案获取用户需求分析系统中已有数据设计报表和编写用户建议编写测试计划编写技术描述设计软件写软件测试软件写说明书执行接受测试设计，写，测试软件将最难估算工作量,22,自顶向下方法,自顶向下的方法和参数化模型一般采用对比方法确定总的工作量对比是建立在一系列参数的基础上的，通过这些参数可以计算出新系统的工作量形式：effort=（系统规模）*（生产率）例如系统
10、规模可以用KLOC来计算，生产率以40天/KLOC预测软件开发工作量的模型有两个部分，第一部分为估算软件大小，第二部分为估算工作效率,23,练习,学生要求每学期写一篇有关IT的报告，如果你想建立一个估算学生完成这样一份报告的模型，你用什么来衡量报告的大小，什么因素会影响学生完成报告的难度？字数材料能否获取对主题的熟悉程度宽度/深度技术难度,24,专家判断,具有应用领域或者开发环境知识的人员对任务的评估该方法特别是在对原由系统进行替换时有用，评估者对影响的代码的比例进行分析，从而得到工作量评估。,25,类比估计,类比方法又被称为基于案例的推理（Case-based reasoning）评估者寻找
11、已经完成的项目，这些项目与需要开发的新项目在许多特征上必须是类似的。如何选择与待预测的项目相近的项目？欧几里的距离（Euclidean Distance）公式distance=（目标系统参数1-原系统参数1）2+（目标系统参数2-原系统参数2）2+）的平方根,26,练习,假定将要构造的系统有7个输入，15个输出，过去有一个项目有8个输入，17个输出，这两个项目的欧几里的距离是多少？答案：2.24,27,Albrecht功能点分析,该方法是由Allan Albrecht在IBM工作时发明的自顶向下方法。功能点法（Function Points）的基本点是计算机信息系统包括五个主要部件或者外部用户
12、类型，它们是：外部输入：应用数据外部输出：提供给用户的面向应用的信息内部逻辑文件：逻辑主文件外部接口文件：与其它系统交换信息外部查询：在线的输入以获得立即的结果,28,功能点方法,加权因子的确定,29,练习,在学院工资系统项目中需要开发一个程序，该程序将从会计系统中提取每年的工资额，并从两个文件中分别提取课程情况和每个老师教的每一门课的时间，该程序将计算每一门课的老师的成本并将结果存成一个文件，该文件可以输出给会计系统，同时该程序也将产生一个报表，以显示对于每一门课，每个老师教学的时间和这些工时的成本。假定报表是具有高度复杂性的，其它具有一般复杂性,30,练习,外部输入：无外部输出：报告，1内
13、部逻辑文件：财务输入文件，1外部接口文件：工资文件，人员文件，课程文件，财务输入文件，4外部查询：无考虑加权：外部输入：无；外部输出：177；内部逻辑文件：11010；外部接口文件：4728；外部查询：无；共：45,31,功能点方法：复杂性判定,如何判定功能的复杂性？国际功能点用户小组（IFPUG)内部逻辑文件、外部接口文件外部输入文件,32,功能点方法：复杂性判定,外部输出文件如何确定记录个数和数据个数如某系统内部逻辑文件：订单文件，包含订单信息（包括订单号，供应商名称，订单日期）和订单项（包括商品号，价格和数目），则记录个数为2，数据个数为6，在表中可以确定该功能点复杂性为低。,33,功能
14、点方法：转换为代码行,通过定义各个功能点对应各种语言的代码行数，则功能点可以转化为代码行一些数据：Cobol:91C:128Quick Basic:64Object Oriented Languages:30,34,MarkII功能点,该方法被作为英国政府项目实施中采用的标准基本原理：对于一个处理事务计算方法：wi输入数据元素we实体wo输出数据元素系数总和为2.5，标准设置为0.58,1.66,0.26,35,MarkII功能点,系数调整，考虑因素：与其它应用的接口特殊的安全特征与第三方的直接交互用户训练特征文档需求,36,功能点的其它扩展,功能点方法起源于业务信息系统应用，因而强调了数据方
15、面的因素而没有考虑功能和行为（控制）方面的因素。特征点（Feature Points):除了考虑普通功能点的内容外，还考虑了算法的特征（矩阵转换，字符串解析，处理中断等都是算法的例子）Boeing提出了一个三维功能点方法（3D）其中三维为数据维，功能维（输入转化为输出的步骤）和控制维（状态之间的转换数）。,37,功能点转化为工作量,对于原来的项目，计算生产率：生产率功能点数目/工作量（人日）则，对于新项目，功能点计算出来后，工作量为：工作量功能点数目/生产率更复杂的方法：最小二乘法即工作量系数1功能点数系数2,38,对象点,Object Points起源于纽约大学的Leonard N.Ster
16、n商学院，它类似于功能点方法，但是更容易计算。对象点方法与面向对象方法并无直接联系。该方法计算应用所需要处理的屏幕，报告和部件，这些都被称为对象。每一对象需要被确定为简单的，中等的，困难的三个层次。,39,对象点方法,40,对象点转换为工作量,首先考虑已经存在的对象应该排除在工作量计算内。即计算新的对象点（NOP）根据原来从事过的项目计算在不同情况下的项目的生产率，例如下表：假定有672个对象点要开发，开发者的经验和工具使用都是一般性的，则需要672/1352个月,41,42,COCOMO:参数化模型,COCOMO：Constructive Cost ModelBoehm在二十世纪70年代采用
17、他的模型对63个项目进行了研究，由于其中只有7个是商务系统，因而它们不仅仅能被用于信息系统。基本的公式为：Effort=csizek其中effort采用“人月(152个工作小时）”pm来度量，size采用kdsi即千行交付源代码指令(thousands of delivered source code instructions),43,COCOMO系数,C,k的取值根据系统的分类而定：根据系统的技术特性和开发环境可以分为：有机模式（organic mode):相对小的团队在一个高度熟悉的内部环境中开发规模较小，接口需求较灵活的系统。嵌入式模式（Embedded Mode)开发的产品在高度约束的
18、条件下进行，对系统改变的成本很高。半分离模式（Semi-detached Mode)两者之间信息系统是有机模式，而实时系统是嵌入式模式。,44,COCOMO系数,系数表：K的值反映了项目越大，则工作量成指数增加，因为大项目需要更多的协调和安排。,45,COCOMO修正,事实上，基本COCOMO模型对工作量的衡量不稳定，Boehm本人也发现了此问题，因而提出名义成本估算的概念。首先从基本模型得到名义成本，然后采用开发成本乘法算子（development effort multiplier,dem)进行修正，即：Pm=Pmnomdem,46,COCOMO成本因素,dem的计算,47,练习,在某企业
19、中，绝大多数系统技术上，产品，计算机和项目等属性都是类似的。只有人员的属性有所差异。该企业制定了下表：分析员非常优秀，编程人员也很优秀但是对该项目面向的领域不熟悉并准备用新的编程语言。他们对操作系统很熟悉。请计算dem。如果名义工作量是4人月，则估算的工作量是多少？,48,练习,49,COCOMOii,针对COCOMO的不足，Boehm开始和其合作者发展了新的模型。该方法利用多种乘法算子和指数。一个明显的特点是该模型适应了项目在执行过程中变得越来越确定的状态，因而是一种渐进性评估。,50,COCOMOII,COCOMOII被分为三个阶段性模型：应用构成阶段（Application Compos
20、ition)：系统的外部特征被设计。在该阶段经常可以采用原型。早期设计（Early Design):基本的软件结构被设计。构造阶段（Post architecture):构造满足要求的系统。,51,COCOMOII,在应用构成阶段，采用对象点计算的方法在早期设计阶段，采用功能点计算的方法。功能点可以转换为SLOC。Pm=Asizesfem1em2emnPm为“人月”工作量，A是一个常数，size以SLOC为单位，sf是规模指数。Sf1.01+0.01因素指数的和,52,COCOMOII,计算规模因素的质量：先前经验（Precedentedness):是否有先前的经验开发的灵活性（Develop
21、ment Flexibility):是否需求能够以多种方式来满足；体系结构/风险解决(Architecture/Risk Resolution)：是否方案已经被确定和解决的程度团队的凝聚性（Team cohesion)过程的成熟性（Process Maturity),53,练习,对于某一个软件企业，一个新的项目的新颖性一般，因而在先前经验方面给3分，开发灵活性方面给以0分，但是需求可能会变化得比较厉害，因而风险解决指数给4分，团队很融洽，给1分，但是过程不标准，因而过程成熟性给4分，请计算规模因素sf：,54,COCOMOII,计算工作量乘法算子em类似于dem的计算在不同的阶段有不同的em如
22、果每一项对于项目而言无特别影响，则取1,55,大致进度估算方法,大致的（Bullpark）进度估算软件估算方程和系数一定程度上比较难掌握软件工作量估算软件比较昂贵大致的估算简单宜行三个进度表可能的最短进度有效的进度普通进度,56,可能的最短进度,非常乐观的假设（员工10顶尖人才，管理，工具，方法）两个事实：存在一个最短的进度，而且不可能突破一个人5天内能写出1000行程序，5个人一天内能完成吗？40个人1小时内能完成吗？当你把进度缩短得比普通进度短时，费用将迅速上涨。,57,58,有效进度与普通进度,有效进度假定人才：顶尖得前25得人才人员调整每年小于6可能的最短进度与有效进度的关系进度变长了
23、，但是工作量也许减少了压缩进度是要付出代价的普通进度（具体表格参考快速软件开发一书）,59,估算修正,经理和客户常问的一个问题“如果我给你额外一个星期做估算，你能修正它以减少不确定性吗？”答应这种要求最后将给自己带来麻烦，因为减少不确定性必须在软件开发过程本身中进行。许多项目中要求给出单点估计，这种方法的结果是估算永远不准确理智的方法是先给出大的区间，逐步缩小区间。,60,估算的再修正,假定有一个6个月的进度计划，计划4周内达到第一个里程碑，而实际上花了5周，如何修正进度：再后续进度中弥补损失的一周把这一周加到进度中整个进度乘以拖延的数量，本例乘以25,61,估算的再修正,1991年对300多
24、个项目的调查表明，项目几乎不能弥补损失的时间（Van Genuchten,1991)第一阶段估算不准确的原因一般会分布再整个项目中,62,估算的技巧,避免无准备的估算不要随口说出一个估算留出估算的时间，并做好计划估算本身也是一个项目开发人员参与估算不要忽略普通任务使用几种不同的估算技术，并比较它们的结果估算的群体讨论,63,过于乐观的进度计划,Microsoft Word for Windows 1.0开发包含249，000行代码，投入660人月，前后历时5年，实际花费时间为预期时间的5倍,64,过于乐观的进度计划,导致WinWord1.0开发延迟的几个主要因素：项目初期制定的开发目标是不可实
25、现的。盖茨下达的指示是用最快的速度开发最好的字处理软件，争取在12月内完成。实现这两个目标中的任何一个都是困难的，同时达到则是不可能的。过紧的进度计划降低了计划的精确度。开发过程中频繁换人。5年中共换了4个组长，其中有2人因进度压力离职，1人是出于健康的原因而离职。迫于进度压力，开发人员匆忙写出一些低质量的和不完整的代码，然后宣称已实现某些性能。这造成了WinWord不得不将用于提高软件稳定性的时间由预计的3个月增加到12个月。由于该项目中，创新比速度更重要，因而试图缩短开发周期，反而使周期变长,65,产生过于乐观的进度计划的根源,为了赶在某些特定时间前展示或出售产品。如计算机交易展示会。管理
26、人员和客户拒绝接受仅给出范围的估算，而是按照他们认为的“最佳”估算来制定进度计划。项目管理人员和开发人员为了享受挑战的乐趣或在压力下工作的刺激，而故意缩短进度计划。管理部门和市场部门为了迎合客户而缩短进度计划。项目管理人员认为较紧的进度计划能够使员工勤奋工作。原先的估计是合理的，但是在项目进行过程中又加进了很多新特性，从而变成了过于乐观的进度。,66,过于乐观的进度计划的后果,进度计划准确性,67,过于乐观的进度计划的后果,计划的质量：错误的假设必将导致无效的项目规划。抛弃计划：当面临进度压力时，大多数开发组织会抛弃原有规划，而走入盲目开发的歧途。如果试图在关键阶段节省时间，必将在后续阶段加倍
27、补偿。分散了管理者的注意力：管理者将分散经历在不断调整计划上。客户关系：项目一拖再拖，客户将失去耐心。,68,过于乐观的进度计划的后果,仓卒收尾要排错只能将系统拆分后再进行，一个小的变动要花很长时间。开发人员清楚地知道系统中存在一些应作修改却未做的地方。测试人员发现错误的速度大于开发人员排错的速度。排除已发现错误的同时，产生了大量新的错误。由于软件变化频繁，难以保证用户文档的同步更新。项目估算多次调整，软件交付日期一拖再拖。,69,超负荷的进度压力,产品质量的降低赌博心理导致风险管理的忽略激励效应不再起作用创造性思维受损精疲力竭：在后面的项目中难以提起热情中途退出：这些人通常是有能力的人长期地
28、进行快速开发：难以补充新知识开发人员与管理人员的关系：不切实际的进度压力会使开发人员丧失对管理人员的尊重。,70,解决之道：有原则的谈判,该谈判的策略的中心是致力于探求一种双赢的解决方案。将人从困境中解脱站在他人的立场上加以考虑（各人有各人的烦恼）以合作的态度来努力改善与管理人员和客户的关系，制定比较现实的进度估算，尽量使各方都能理解进度估算的意义。不要针锋相对,71,有原则的谈判,关注共同利益，不要过分坚持立场有时候必须作出让步可以从下列几个方面加以说服：真正提高开发速度增加成功的机会引用以前类似项目的失败教训,72,有原则的谈判,提出多种备选方案1、与产品有关的灵活变通：将一些设计功能放到
29、下一版本实现，大多数人在提出需求时，并不清楚这些需求是否必须全部在当前版本被满足。分阶段交付产品。如版本0.7.0.8,0.9,1.0，每版实现最迫切的功能。砍去某些实现起来费时或者需要谈判后才能确定的特性，包括与其它系统的整合能力。与旧版本兼容的能力，以及产品性能等。对某些特性不必精雕细琢，只需实现到某种程度即可。尽量轻松地实现各特性地详细功能需求。可以通过一些商业组件来实现。,73,有原则的谈判,与项目资源有关的灵活变通如果处于项目初期，则增加更多的开发人员增加高层次的开放人员（如领域专家）增加更多的测试人员在管理方面给予更多的支持提高开发的支持力度，如更安静，更独立的工作间，速度更快的计
30、算机，技术人员随时维护环境提高最终用户的参与度，最好在项目组中配备一个能够对特性设置最终拍板的用户提高主管人员的参与度,74,有原则的谈判,3.与进度计划有关的灵活变通在详细设计，产品设计，或至少是需求分析完成之前，只提出一个进度目标，但不设定一个确切期限如果是在项目初期，则在提炼产品概念，功能要求合详细设计时，可以探求缩短开发时间的方法先给出进度估算范围或大概的进度估算值，然后随着项目的进展逐步精确4.其他为开发人员提供额外的支持，以保证他们能集中精力于项目的开发，例如购物服务，供餐，洗衣，清洗住所等采取更多的激励措施，如休假旅游，加班工资等,75,有原则的谈判,坚持客观标准只能向原则低头，而不能向压力屈服谈判不要局限于估算本身，即可以考虑项目的输入条件有条件的话，可以由专业估算机构进行估算坚持科学的估算过程顶住压力,76,小结,软件工作量估算的特点软件工作量估算困难的原因估算的基本方法功能点方法和COCOMO模型估算技巧过于乐观的估计有原则的谈判,
