IT项目管理教程之六课件

《IT项目管理教程之六课件》由会员分享，可在线阅读，更多相关《IT项目管理教程之六课件（76页珍藏版）》请在金锄头文库上搜索。

1、1,讲座6 软件项目工作量估算,2,软件工作量估算,有些估算做得很仔细，而有些却只是凭直觉的猜测。大多数项目超过估算进度的25%到100，但也有少数一些组织的进度估算精确到了10以内，能控制在5以内的还没有听说。 Jones,1994,3,软件工作量估算,“大多数IS人士，无论是否为管理者，从来都无权控制他们自己的进度计划。进度计划通常由市场部或高层管理部门直接下达，就像飞石从天而降（也有人称之为鸟粪）” “就此问题，我曾与IS领域中许多人士进行过交流。大家一致认为当前IS领域面临的最大难题，既不是掌握快速更新的技术，也不是探求新型的管理哲学，而是被迫接受根本无法达到的进度计划。”（Rober

2、t.L.Glass),4,一个月的时间造这样一栋房子？没问题,太好了，那我们开工吧！,你当初计划10万元造的房屋可能最终的实际造价为50万元。,5,从造房子中学到的,除非你确切知道“它”是什么？否则无法说明它的确切花费。 盖房子时，可以盖梦想中的房子（不考虑花费），也可以按估算盖，但是功能必须具有一定的灵活性,6,不确定性问题,客户会要求功能吗？ 客户要的是功能的便宜版本还是昂贵版本呢？同一功能的不同版本的实施难度至少有10左右的差别。 如果实施了功能的便宜版本，客户会不会以后又想要昂贵的版本。 功能如何设计？同一功能的不同设计，在复杂度方面会有10左右的差别。 功能的质量级别是什么？依据实施

3、过程的不同，首次提交的功能的缺陷数量会有10的差异。 调试和纠正功能实施过程中的错误要花多少时间？研究发现调试和纠正同样的错误，不同程序员所花时间会有10左右的差异。 把功能和其它功能结合起来要花多少时间？ ,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, 1

8、991) 承诺应该现实可行，以使你的团队会不断成功而不是不断失败。,18,软件工作量估计技术,算术模型 专家判断 对比法 Parkinson：能够使用的参与该项目的人力 赢利价格：赢得合同的价格 自顶向下：首先定义整个项目的工作量，然后分解到各个部分 自下而上：各个部分的工作量先估算出来，然后进行合成,19,自底向上方法,该方法首先将项目分成部件任务，然后估算每个任务所需的工作量。 在大型的项目中，分解任务的过程是一个叠代的过程，直到最下面的任务不可分解，产生WBS。 该方法适合于项目规划的后期。如果应用在前期，那么必须对最终的系统作出一些假设，例如对软件模块的数量和大小进行假设。 如果项目是

9、全新的或者没有历史数据，建议用该方法,20,练习,工资系统已经被安装在Brightmouth学院，目前有一个新的需求，需要在系统中添加一个子系统，该系统分析每节课时老师的成本。每个老师的工资可以从系统中获得，每个老师花在每个课程上的时间也可以从系统中获得。为了实现该系统，需要哪些任务，哪些任务的工作量比较难计算。,21,练习,答案 获取用户需求 分析系统中已有数据 设计报表和编写用户建议 编写测试计划 编写技术描述 设计软件 写软件 测试软件 写说明书 执行接受测试 设计，写，测试软件将最难估算工作量,22,自顶向下方法,自顶向下的方法和参数化模型 一般采用对比方法确定总的工作量 对比是建立在

10、一系列参数的基础上的，通过这些参数可以计算出新系统的工作量 形式： effort=（系统规模）*（生产率） 例如系统规模可以用KLOC来计算，生产率以40天/KLOC 预测软件开发工作量的模型有两个部分，第一部分为估算软件大小，第二部分为估算工作效率,23,练习,学生要求每学期写一篇有关IT的报告，如果你想建立一个估算学生完成这样一份报告的模型，你用什么来衡量报告的大小，什么因素会影响学生完成报告的难度？ 字数 材料能否获取 对主题的熟悉程度 宽度/深度 技术难度,24,专家判断,具有应用领域或者开发环境知识的人员对任务的评估 该方法特别是在对原由系统进行替换时有用，评估者对影响的代码的比例进

11、行分析，从而得到工作量评估。,25,类比估计,类比方法又被称为基于案例的推理（Case-based reasoning） 评估者寻找已经完成的项目，这些项目与需要开发的新项目在许多特征上必须是类似的。 如何选择与待预测的项目相近的项目？ 欧几里的距离（Euclidean Distance）公式 distance=（目标系统参数1-原系统参数1）2+（目标系统参数2-原系统参数2）2+）的平方根,26,练习,假定将要构造的系统有7个输入，15个输出，过去有一个项目有8个输入，17个输出，这两个项目的欧几里的距离是多少？ 答案：2.24,27,Albrecht功能点分析,该方法是由Allan Al

12、brecht在IBM工作时发明的自顶向下方法。 功能点法（Function Points）的基本点是计算机信息系统包括五个主要部件或者外部用户类型，它们是： 外部输入：应用数据 外部输出：提供给用户的面向应用的信息 内部逻辑文件：逻辑主文件 外部接口文件：与其它系统交换信息 外部查询：在线的输入以获得立即的结果,28,功能点方法,加权因子的确定,29,，在学院工资系统项目中需要开发一个程序，该程序将从会计系统中提取每年的工资额，并从两个文件中分别提取课程情况和每个老师教的每一门课的时间，该程序将计算每一门课的老师的成本并将结果存成一个文件，该文件可以输出给会计系统，同时该程序也将产生一个报表，

13、以显示对于每一门课，每个老师教学的时间和这些工时的成本。 假定报表是具有高度复杂性的，其它具有一般复杂性,30,练习,外部输入：无 外部输出：报告，1 内部逻辑文件：财务输入文件，1 外部接口文件：工资文件，人员文件，课程文件，财务输入文件，4 外部查询：无 考虑加权： 外部输入：无；外部输出：177；内部逻辑文件：11010；外部接口文件：4728；外部查询：无；共：45,31,功能点方法：复杂性判定,如何判定功能的复杂性？ 国际功能点用户小组（IFPUG) 内部逻辑文件、外部接口文件 外部输入文件,32,功能点方法：复杂性判定,外部输出文件 如何确定记录个数和数据个数 如某系统内部逻辑文件

14、：订单文件，包含订单信息（包括订单号，供应商名称，订单日期）和订单项（包括商品号，价格和数目），则记录个数为2，数据个数为6，在表中可以确定该功能点复杂性为低。,33,功能点方法：转换为代码行,通过定义各个功能点对应各种语言的代码行数，则功能点可以转化为代码行 一些数据： Cobol: 91 C: 128 Quick Basic: 64 Object Oriented Languages: 30,34,MarkII功能点,该方法被作为英国政府项目实施中采用的标准 基本原理：对于一个处理事务 计算方法：wi输入数据元素we实体wo输出数据元素 系数总和为2.5，标准设置为0.58, 1.66,0

15、.26,35,MarkII功能点,系数调整，考虑因素： 与其它应用的接口 特殊的安全特征 与第三方的直接交互 用户训练特征 文档需求,36,功能点的其它扩展,功能点方法起源于业务信息系统应用，因而强调了数据方面的因素而没有考虑功能和行为（控制）方面的因素。 特征点（Feature Points):除了考虑普通功能点的内容外，还考虑了算法的特征（矩阵转换，字符串解析，处理中断等都是算法的例子） Boeing提出了一个三维功能点方法（3D）其中三维为数据维，功能维（输入转化为输出的步骤）和控制维（状态之间的转换数）。,37,功能点转化为工作量,对于原来的项目，计算生产率： 生产率功能点数目/工作量

16、（人日） 则，对于新项目，功能点计算出来后，工作量为： 工作量功能点数目/生产率 更复杂的方法：最小二乘法 即工作量系数1功能点数系数2,38,对象点,Object Points起源于纽约大学的Leonard N.Stern商学院，它类似于功能点方法，但是更容易计算。 对象点方法与面向对象方法并无直接联系。 该方法计算应用所需要处理的屏幕，报告和部件，这些都被称为对象。每一对象需要被确定为简单的，中等的，困难的三个层次。,39,对象点方法,40,对象点转换为工作量,首先考虑已经存在的对象应该排除在工作量计算内。即计算新的对象点（NOP） 根据原来从事过的项目计算在不同情况下的项目的生产率，例如下表： 假定有672个对象点要开发，开发者的经验和工具使用都是一般性的，则需要672/1352个月,41,42,COCOMO: 参数化模型,COCOMO：Constructive Cost Model Boehm在二十世纪70年代采用他的模型对63个项目进行了研究，由于其中只有7个是商务系统，因而它们不仅仅能被用于信息系统。 基本的公式为： Effort=