软件项目管理讲座6[1]软件工作量估算

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