《软件项目管理》PPT课件.ppt

chapter_4,0,软件开发项目管理,信息管理系 汪维清,chapter_4,1,承上启下,chapter_4,2,成本计划,chapter_4,3,软件开发项目管理,第 4 章 软件项目成本计划,chapter_4,4,4.1 关于估算,估算一般可能不是非常的准确，尤其是软件更是如此，软件项目中存在太多的不确定性，而且，在项目初期，人们对需求喝技术的不了解还不是很透彻。 对于估算既没有特效的办法，也没有通用的模型，项目经理可以根据以前的项目经验和验证过的指南来提高精度。,chapter_4,5,4.1.1 项目规模与成本的关系,软件项目规模即工作量，是从软件项目范围中抽出的软件功能，然后确定每个软件功能所必须执行的一系列软件工程任务 包括：软件规划，软件管理，需求，设计，编码，测试，以及后期的维护等任务。 软件项目成本是指完成软件项目规模相应付出的代价，是待开发的软件项目需要的资金。 规模的单位：代码行（line of code，LOC）、功能点、人天、人月、人年等 成本一般采用货币单位，如人民币或美元等,chapter_4,6,4.1.2 成本估算的定义,软件开发成本是指软件开发过程中所花费的工作量及相应代价。 软件开发成本的估算应该从软件计划、需求分析设计、编码、单元测试、集成测试到接受测试等这些过程中所花费的代价作为依据。,chapter_4,7,4.2 估算的过程,成本管理就是确保项目在预算范围之内的管理过程，包括成本估算、成本预算、成本控制等过程。 成本估算涉及计算完成项目所需各资源成本的近似值。 由于影响软件成本的因素太多（例如人、技术、环境、政治等），软件估算仍然是恨不成熟的技术，一些方法只能作为借鉴，更多的时候需要经验。目前没有一个估算方法或者成本估算模型可以适用于所有的软件类型和开发环境,chapter_4,8,4.2.1 成本估算输入,估算的输入一般包括以下几项： 项目需求或WBS：根据估算的不同阶段，有不同的输入可用于成本估算，以确保所有工作均一一被估计进成本了 历史项目数据：是以往项目的数据，包括规模、进度、成本等，是项目估算的主要参考 资源要求（资源编制计划）：它可以让项目组掌握资源需要和分配的情况 资源消耗率:即资源单击，如人员成本: 100元/小时 进度规划：项目活动时间的估计，活动时间估计会影响到项目成本估计 学习曲线：是项目组学习某项技术或者工作的时间，当一件事情被重复的时候，完成这件事情的时间将会被缩短，业绩会以一定的百分比提高,chapter_4,9,4.2.2 估算处理,成本估算包括直接成本和间接成本。 直接成本是与开放的具体项目直接相关的成本，如人员的工资、材料费、外包外购成本等，包括开放成本、管理成本、质量成本等 间接晨报归属于一个具体项目，可以分摊到各个具体项目中的成本，例如：培训、房租水电、员工福利、市场费用、管理费等等,chapter_4,10,4.2.3 估算输出,成本估算的结果可以以简略或详细的形式表示。对项目所需的各种资源的成本均需加以估计。估算单位通常是货币单位，如元、法郎、美元等；也可以用人月、人天或人小时这样的单位 估算文件包括项目所需的资源，资源的数量，质量标准，估算成本等信息，单位一般是货币单位 估算说明包括工作范围、估算的基础和依据、估算的假设、估算的误差变动等,chapter_4,11,4.3 成本估算的方法,常用的成本估算方法如： 代码行、功能点 类比 (自顶向下)估算法 自下而上估算法 参数法估算法 专家估算法,chapter_4,12,4.3.1 代码行（LOC）、功能点及对象,代码行、功能点是表达软件项目规模的单位，有时也称为软件项目规模估算方法,chapter_4,13,1 代码行,这种方法依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序航数。 使用代码行作为规模单位时，要求功能分解足够详细，而且有一定的经验数据，采用不同的开发语言，代码行可能不一样。 代码行技术的主要优点：代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。 代码行（LOC）缺点： 对代码行没有公认的可接受的标准定义 代码行数量依赖于所用的编程语言和个人的编程风格. 在项目早期,需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量. 代码行强调编码的工作量,只是项目实现阶段的一部分,chapter_4,14,2. 功能点（FP: Function point）,（1）基本概念 功能点是用系统的功能数量来测量其规模，它以一个标准的单位来度量软件产品的功能，与实现产品所用的语言和技术没有关系。 功能点计算公式：FP =UFC*TCF UFC：未调整功能点计数 TCF：技术复杂度因子,chapter_4,15,（2）UFC-未调整功能点计数,在功能点分析中，系统被分为5类组件和一些常规系统特征 在计算未调整功能点计数时，应该先计算5类功能组件的计数项： 内部逻辑文件（ILF）：是用户可以识别的一组逻辑相关的数据，而且完全存在于应用的边界之内，并且通过外部输入维护 外部输入（EI）：给软件提供面向应用的数据项（如屏幕、菜单、对话框、控件等），在这个过程中，数据穿越外部边界进入系统内部。 外部输出（EO）：向外部提供面向应用的信息，如报表和出错信息等 外部查询（EQ）：即一次联机输入，它导致软件以联机输出方式产生某种及时响应 外部文件（EIF）：是用户可以识别的一组逻辑相关数据，这组数据只能被引用,chapter_4,16,当组件被规为以上5类主要组件中的一类以后，就要为之指定级别，所有组件都被指定为高、中、低三个级别。它们的级别取决于被更新或引用文件的个数以及数据元素类型的个数。,外部输入定级表,外部输入和外部查询共用定级表,外部输入、外部输出和外部查询共用定级取值,chapter_4,17,内部逻辑文件或者外部接口文件定级,组件复杂度表,内部逻辑文件或者外部接口文件级数取值,将每个类别组件的每一级复杂度输入到组件复杂度表中，每一组件的数量乘以所示的级数得出定级的值,chapter_4,18,(3) TCF-技术复杂度因子,技术复杂度因子取决于14个通用系统特性。影响程度的取值从0到5，从没有影响到强烈影响。计算复杂度因子公式如下： TCF=0.65+0.01(sum(Fi)： Fi:0-5,TCF:0.65-1.35,chapter_4,19,【例1】一个软件的五类功能计数项如下左图，计算这个软件的功能点 1）计算UFC：按照UFC的计算过程如下右图，得UFC301 2）计算TCF：按公式计算得TCF=0.65+0.01(14*3)=1.07 3）计算FP：按公式计算得FP=301*1.07=322,chapter_4,20,（4） 功能点与代码行的转换,功能点可以按照一定的条件转换为代码行，是针对各种语言的转换率，它是根据经验的研究得出的。如表所示：,chapter_4,21,4.3.2 类比估算法,估算人员根据以往的完成类似项目所消耗的总成本（或工作量），来推算将要开发的软件的总成本（或工作量），然后按比例将它分配到各个开发任务单元中 是一种自上而下的估算形式 对于度量相似度，目前的研究中常有两种求值方式来度量差距，即不加权的欧式距离和加权的欧式距离：,chapter_4,22,类比举例,chapter_4,23,对于工作量最后估算值的确定，有不同的方法,如： 可以直接取最相似的项目的工作量（对应P0工作量取1000） 可以取几个相似的项目的工作量的平均值（对应P0工作量取1900/2=950） 目前，类别估算的方法，基本上采用主观推测，很少采用相似度计算的方法,chapter_4,24,4.3.3 自下而上估算法,利用任务分解结构图,对各个具体工作包进行详细的成本估算,然后将结果累加起来得出项目总成本。 自下而上使用情况： 项目开始以后，WBS的开发阶段； 需要进行准确估算的时候 自下而上特点： 这种方法相对比较准确，它的准确度来源于每个任务的估算情况 非常费时,估算本身也需要成本支持 可能发生虚报现象,chapter_4,25,4.3.4 参数模型估算法,参数模型估算法也称算法模型或者经营导出模型，是一种使用项目特性参数建立数据模型来估算成本的方法，是一种统计技术，如回归分析和学习曲线。 其基本思想是：找到软件工作量的各种成本影响因子，并判断它对工作量所产生的影响程度是可加的、乘数的还是指数的，以期得到最佳的模型算法表达形式。 当某个因子只影响系统的局部时，我们一般说它是可加的，如：给系统增加源指令、功能点实体、模块等 当某个因子对整个系统具有全局性的影响时，则说它是乘数的或指数的。如：增加服务需求的等级或者不兼容的客户等,chapter_4,26,（1）静态单变量模型,这类模型的总结构形式如下： E=A+B*SC E:以人月表示的工作量 A,B,C:经验导出的系数 S:主要的输入参数(通常是LOC,FP等）,chapter_4,27,以下为几个典型的静态单变量模型： 面向LOC的估算模型 Walston-Felix(IBM) E= 5.2*(KLOC)0.91 Balley-Basili E=5.5+0.73*(KLOC)1.16 .COCOMO E=3.2*(KLOC)1.05 Doty E=5.288*(KLOC)1.047 面向FP驱动的 Albrecht and Gaffney E=-12.39+0.0545FP Matson,Barnett E=585.7+15.12FP,chapter_4,28,（2）动态多变量模型,动态多变量模型也称为软件方程式，该模型把工作量看作是软件规模和开发时间这两个变量的函数 E=(LOC*B0.333/P)3*(1/t)4 E:以人月表示的工作量 t：以月或年为单位的项目持续时间 B：特殊技术因子，随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加 P：生产率参数，可从历史数据导出适用于当前项目的生产率参数值 对较小的程序（KLOC5-15），B0.16 对超过70KLOC的程序，B0.39 开发嵌入式软件时，P的典型值为2000；开发电信系统和系统软件时，P10000；对商业系统P28000,chapter_4,29,COCOMO（Constructive Cost model）模型,参数模型估算方法适合于比较成熟的软件企业，其中COCOMO模型是一种结构化成本模型 ，也是世界上应用最广泛的参数型软件成本估计模型 由Barry Boehm开发的 COCOMO模型通用公式： 其中，PM为工作量，通常表示为人月；A为校准因子；Size为对工作量呈可加性影响的软件模块的功能尺寸的度量；B为工作量呈指数或非线性影响的比例因子；EM为影响软件开发工作量的工作量乘数。,chapter_4,30,COCOMO模型发展,COCOMO 81 COCOMO II 模型系列,chapter_4,31,1. COCOMO 81,COCOMO 81有3个等级的模型： 基本COCOMO：在项目相关信息极少的情况下使用； 中等COCOMO：在需求确定以后使用 高级COCOMO：在设计完成后使用 COCOMO 81的3个等级模型也满足类似的通用公式：Efforta（KLOCK）bF 其中：Effort为工作量，表示为人月；a和b为系数，具体取值取决于建模等级（即基本、中等或高级）以及项目的模式（有机、半嵌入型或嵌入型）,chapter_4,32,1. COCOMO 81,COCOMO 81将项目的模式分为： 有机: Organic， 各类应用程序，例如数据处理、科学计算 等 受硬件的约束比较小，程序的规模不是很大 嵌入式: Embedded 系统程序，例如实时处理、控制程序等 紧密联系的硬件、软件和操作的限制条件下运行，软件规模任意 半有机: Semidetached 各类实用程序，介于上述两种软件之间，例如编译器（程序） 规模和复杂度都属于中等或者更高,chapter_4,33,（1）基本COCOMO,E= a(KLOC)exp(b) 其中： E是所需的人力（人月）， KLOC是交付的代码行 a ， b是依赖于项目自然属性的参数：,chapter_4,34,举例,一个33.3 KLOC的软件开发项目，属于中等规模、半有机型的项目，采用基本COCOMO： a=3.0，b=1.12。 E = 3.0L 1.12 = 3.033.3 1.12 = 152 PM,chapter_4,35,（2）中等COCOMO,E=a(KLOC)exp(b)*乘法因子 a b是系数 乘法因子是根据成本驱动属性打分的结果，对公式的校正系数,chapter_4,36,乘法因子属性,产品属性 平台属性 人员属性 过程属性,chapter_4,37,乘法因子,chapter_4,38,乘法因子计算,每个属性Fi的取值范围为： 很低、低、正常、高、很高、极高，共六级。 正常情况下 Fi=1。 当每个Fi的值选定后，乘法因子的计算如下 乘法因子F1*F2* Fi * Fn,chapter_4,39,举例（续）,一个33.3 KLOC的软件开发项目，属于中等规模、半有机型的项目，采用中等COCOMO模型 a=3.0，b=1.12。 乘法因子0.70*0.85*1*1.15=1.09 E = 3.0L 1.12 = 3.033.3 1.12 PM,chapter_4,40,（3）高级（详细）COCOMO,将项目分解为一系列的子系统或者子模型 在一组子模型的基础上更加精确地调整一个模型的属性， 高级COCOMO模型的工作量计算公式与中等COCOMO模型相同，其主要区别在于： 将待估算的软件项目分解为模块、子系统、系统3个等级 增加了与开发阶段相关的工作量乘数，它可以准确反映成本驱动因子对工作量阶段分布的影响,chapter_4,41,chapter_4,42,4.3.5 专家估算法,专家估算是由一个被认为是该任务专家的人来进行估算，并且估算过程的很大一部分是基于不清晰、不可重复的过程，也就是直觉。 由多位专家进行成本估算，一个专家可能会有偏见，最好由多位专家进行估算，取得多个估算值,最后得出综合的估算值。,chapter_4,43,专家估算法-Deiphi,组织者发给每位专家一份软件系统的规格说明和一张记录估算值的表格，请他们估算 专家详细研究软件规格说明后，对该软件提出3个规模的估算值 最小ai 最可能的mi 最大bi 组织者对专家的表格中的答复进行整理，计算每位专家的Ei=(ai+4mi+bi)/6,然后，计算出期望值：E=E1+E2+En/n（N:表示N 个专家）,chapter_4,44,专家估算法-Deiphi(续),综合结果后，再组织专家无记名填表格，比较估算差，并查找原因 如果各个专家的估算差异超出规定的范围（例如：15%），则需重复上述过程 ，最终可以获得一个多数专家共识的软件规模,chapter_4,45,专家估算法-举例,某多媒体信息查询系统专家估算 专家1：1，8，9=（1+9+4 * 8 ）/6=7（万元） 专家2： 4， 6 ， 8 =（4+8+4*6）/6=6 （万元） 估算结果=（6+7）/2=6.5 （万元）,chapter_4,46,4.3.6 猜测法,猜测法是一种经验估算法，进行估算的人有专门的知识和丰富的经验，据此提出一个近似的数据，是一种原始的估算方法。 此方法只适用于要求很快拿出项目的大概数字的情况，对于要求详细估算的项目是不适合的,chapter_4,47,4.3.7 成本估算方法综述,主要考虑三种模型:类比法,自下而上法,参数法. 自下而上法费时费力,参数法比较简单 自下向上法与参数法的估计精度相似 类比法通常用来验证参数法和自下而上法的结果 各种方法不是孤立的,应该注意相互的结合使用,chapter_4,48,实用软件估算模型,是一种自下而上和参数法的结合模型,步骤如下: 对任务进行分解:1,2,i 估算每个任务的成本Ei 直接成本=E1+E2+ Ei+ En 项目总估算成本= 直接成本+间接成本 项目总报价=项目总估算成本+风险利润 风险利润=利润+风险基金+税,chapter_4,49,估算每个任务的成本,直接估算成本Ei 先估算规模Qi，然后估算成本Ei= Qi *人力成本参数 唯一估计值：Qi=Avg PERT算法: Qi=(Max+4Avg+Min)/6,chapter_4,50,直接成本估算,直接成本=规模*人力成本参数 直接成本组成 开发成本 管理成本 质量成本 例如：人力成本参数=2万/人月，30人月规模的项目的直接成本是 60万,chapter_4,51,直接成本估算简易估算：,开发（工作量）规模： Scale(Dev) (单位：人月) 管理、质量（工作量）规模： Scale(Mgn)=a* Scale(Dev) a为比例系数：例如：20%-25% 直接成本 Scale(Dev) a* Scale(Dev),退出,chapter_4,52,项目总估算成本,估算成本=直接成本+间接成本 间接成本估算： 按照企业模型直接估算： 简易算法： 间接成本=直接成本*间接成本系数 间接成本= 规模*人力成本参数*间接成本系数 例如：间接成本系数=0.3,chapter_4,53,项目总估算成本,估算成本=直接成本+间接成本 估算成本=直接成本+直接成本*间接成本系数 估算成本=直接成本(1+间接成本系数) 估算成本=规模*人力成本参数（1+间接成本系数） 成本系数=人力成本参数* （1+间接成本系数） 简易算法： 估算成本=规模*成本系数 例如：成本系数= 3万/人月,退出,chapter_4,54,项目总报价,项目总报价=项目总估算成本+风险利润 项目利润=估算成本*a% 风险基金=估算成本*b% 税=估算成本*c% (例如:c为5.5左右) 项目总报价=(a+b+c) %*项目总估算成本+项目总估算成本,chapter_4,55,4.4 估算的误差度,一般说，进行规模成本估算都存在一定的误差。误差的大小会因项目的不同、因项目阶段的不同而有所不同,chapter_4,56,1.估算的误差,项目估算在不同的阶段会有不同的误差，常规估算准确度的统如表,chapter_4,57,2. 估算不准的原因,基础数据不足 缺乏经验的估算人员 签约前后不连贯：签约前，销售人员为了拿到项目，而夸大了承诺，或者削减了价格 低劣的推测技术 估算对需求的敏感性,chapter_4,58,3.对付估算误差的方法,避免无准备的估算 留出估算的时间，并做好计划 使用以前的项目数据 使用开发人员提供的数据为基础估算 分类法估算 详细的较低层次上的估算 使用软件估算工具 使用几种不同估算技术，并比较它们的结果,chapter_4,59,估算的表达方式技巧,加减限定 6个人月，+3人月，-1人月 范围 5-9人月,chapter_4,60,估算的表达方式技巧,3.风险量化: 见下例,chapter_4,61,估算的表达方式技巧,4.情况： 见下：案例估算的例子,chapter_4,62,软件工程中的真相与假象,该书总结了55个真相和10个假象，其中直接与估算有关的7个真像和1个假象： 真相8:造成软件项目失控最普遍的两个原因之一就是软件估算不足(另外的原因是需求不稳定). 真相9:往往在错误的时间,甚至在没有定义需求也即没有理解问题之