项目估算与项目成本管理

软件项目管理王颖2软件项目管理什么是项目？如何获得项目？如何管理项目？怎样提交项目？结项后应做什么？需求前延质量检验过程项目需求的实际验证课程体系3成本管理的内容成本大体包括4个方面：人力资源成本、软硬件资源成本、商务活动成本、其他成本费用。成本管理活动包括的内容：软件系统规模估算软件项目成本估算软件项目成本预算制定软件项目成本监控4软件项目管理的关键技术…………需求管理…………成本估算…………进度管理…………成本管理…………配置管理…………风险管理…………质量管理…………资源管理5成本估算(ProjectEstimation)6软件项目成本估算软件项目成本估算基本概念软件项目成本估算技术成本估算要进行成本控制，首先要进行成本估算。成本估算是在一个无法以高可靠性预计的环境下进行的，在软件项目管理过程中，为了使时间、费用和工作范围内的资源得到最佳利用，人们开发出了不少成本估算方法。79如果没有软件项目估算……一个月没问题！！一个月后大概还需要一年吧！10时机选择的标准项目早期，估算精度低、意义大项目后期，估算精度高、意义小项目结束，估算精度100%，无意义估算本身需要成本，过多估算导致项目成本上升多次估算可以提高精度项目分为多个阶段，阶段性估算可以指导后续工作……11软件项目估算的时机软件产品生命周期计划软件产品开发软件产品验证软件产品使用软件产品淘汰软件产品软件估算产品定义客户需求系统设计系统实现系统测试系统评审系统运行系统维护系统升级更换系统E1E2E3E4E5原始估算初级估算二级精算估算结果估算申请形式化模块划分细化实现估算体12软件项目估算的时机E1客户需求客户需求阶段列出了客户需要的基本软件功能，时间点E1的估算可以为软件组织提供初步信息，以决定即将开始的软件项目是否对本组织有利。如果答案是肯定的，则进入下一阶段的工作，否则就需要重新考虑项目的可行性了。E2产品定义产品定义阶段完成对软件项目的规格说明，进一步细化了系统功能，为系统设计提供了依据。此时的估算有助于软件组织在进入产品开发之前再次权衡产品的可行性。E3系统设计系统设计阶段给出了产品的完整软件体系结构和各个子系统及模块的说明，该阶段的估算工作要考虑的是如何将设计好的系统开发出来及有没有被忽视的问题。这阶段的估算一般不会做出终止项目的决定，但却会影响以后各阶段的资源分配。13软件项目估算的时机E4系统实现设计通过审查之后，系统的实现工作就开始了。此时需要大量的程序员参与，因而人员数量会达到高峰，然后随着实现的完成而降下去。该阶段结束时，初步的软件产品可用于系统测试，前面各项活动中耗费的资源（时间及人力等）和软件工作量均可以获得，从而可对原有估算进行调整，后期需要的工作则按此估算进行计划。E5系统运行当所有的工作都已完成并得到了验证之后，系统就可以投入运行了。此时，所有的不确定因素都成为已知量，估算工作实际上是对估算过程的评价，即用实际的消耗与各个阶段估算值进行比较。这一阶段的估算看似无用，其实对于软件组织来说是必不可少的，它使得软件组织能够认识到估算活动中需要提高的地方及组织本身的特点，为下一个项目积累了宝贵的经验。14软件项目估算的时机估算意义项目进展估算精度项目进展估算进行越早，意义越大估算进行越晚，精度越高15影响估算结果的因素失败因素：无根据的估算完全不可信人们容易低估小项目的工作量，而过分夸大大项目的工作量成功因素：留出估算的时间，并做好计划估算本身也是一个项目开发人员参与估算，并使用几种不同的估算技术，并比较它们的结果据估计，规模小于10万行代码的工作被低估的比例达60%，而百万行级的工作被高估的比例为80%！16影响估算结果的因素（续）失败因素：多些时间做估算，并不能得到更准确的结果单点估计的结果往往不正确成功因素：估算的群体讨论，依靠更多的意见而不是时间提高估算准确度理智的方法是先给出大的区间，在软件开发过程本身中逐步缩小区间17案例：过分乐观的估算MicrosoftWordforWindows1.0开发。包含249，000行代码，投入660人月，前后历时5年，实际花费时间为预期时间的5倍18案例分析（续）导致WinWord1.0开发延迟的几个主要因素：①项目初期制定的开发目标是不可实现的。①盖茨下达的指示是用最快的速度开发最好的文字处理软件，争取在12月内完成。实现这两个目标中的任何一个都是困难的，同时达到则是不可能的。②过紧的进度计划降低了计划的精确度。③开发过程中频繁换人。5年中共换了4个组长，其中有2人因进度压力离职，1人是出于健康的原因而离职。19案例分析（续）④迫于进度压力，开发人员匆忙写出一些低质量的和不完整的代码，然后宣称已实现某些性能。这造成了WinWord不得不将用于提高软件稳定性的时间由预计的3个月增加到12个月。⑤由于该项目中，创新比速度更重要，因而试图缩短开发周期，反而使周期变长20案例总结①高层的决定不总是睿智的启示：估算应该征求所有项目相关人员的意见没有最快，只有更快！21案例总结（续）②过大的压力带来意想不到的结果一个月作完！20天作完！！……22案例总结（续）③Brook法则：当人数增加后，项目所需的工作量将不成比例的增加。管理通信协调更低的工作效率启示：不是越多人越好，而是合适的人最好23软件项目估算的基础历史数据在参考历史数据时需要考虑不同的环境。如编程语言，软件工具，复杂程度，标准和人员的经验。历史数据24软件项目估算的基础（续）工作度量直接计算真正的成本或时间是不可能的。编写相同的程序，不同的人将有显著的区别。通常将工作量表达为如源代码的数量（LOC），或者千行代码量（KLOC）；或表达为功能点数（FP）。复杂性相同KLOC的两个程序花费的时间将会不同，要根据复杂性进行修正，但是复杂性的度量通常是主观的25软件项目估算软件项目估算基本概念软件项目估算技术26软件成本估算技术软件规模是软件成本的主要因素，对软件规模的估计要从软件的分解开始。软件项目的设计有一个分层结构，这一分层结构就对应着工作分解结构（WBS）。如下图：27软件成本估算技术软件规模估算技术：代码行（LOC）、功能点（FP）、计划评审技术(PERT)软件成本估算技术：类比、自顶向下、自底向上、专家判定、算法模型常用成本估算模型：COCOMO模型、COCOMOⅡ模型和Putnam模型。代码行估算代码行（LOC）估算是最基本、最简单的软件规模估算方法，应用较普遍。LOC分为无注释的源代码行（NCLOC）和注释的源代码行（CLOC）。LOC=NCLOC+CLOC由于LOC单位比较小，在实际工作也常常使用KLOC（千代码行）来表示程序的长度。28代码行估算1代码行价值和人月均代码行数可以体现一个软件生产组织的生产能力，组织可以根据对历史项目的审计来核算组织的单行代码价值。如：某公司统计发现该公司每10KLOC的C语言源代码形成的文件约为250KB，某项目文件大小为2.5MB，则可以估计该项目源代码有102.4KLOC。若累计投入工作量为160人月，每人月费用为10000元，则1LOC的价值约为15.6元，人月均代码行数约为641LOC/人月。29功能点方法功能点方法（FP）是在需求分析阶段基于系统功能的一种规模估计方法，基本思想是：通过研究初始应用需求来确定各种输入、输出、查询、外部文件和内部文件的数量和特性，从而计算出功能点。该方法不需要开发组织的类似历史数据。该方法在一下情况下特别有用：（1）估计新的软件开发项目（2）应用软件包括很多输入输出或文件活动（3）拥有经验丰富的FP估算专家（4）拥有充分的数据资料，可以相当准确地将FP转化为LOC。30功能点方法计算公式：FP=UFC×TCF31未调整功能点数技术复杂度因子功能点方法—未调整功能点数UFC计算公式：UFC=功能项的加权和32输入、输出、查询、外部文件、内部文件功能点的复杂度权重33功能点方法功能点的复杂度权重功能项权重简单一般复杂输入46输出45查询346外部文件71015内部文件5710范例：现假设一项目的功能项中只含两个简单的输入和三个复杂的输出，则原始功能点为UFC=237×3+3×7=27TCF共有14个组成部分，每个部分按照其对系统的重要程度分为6个级别，有影响、影响很小、有一定影响、重要、比较重要和很重要，相应赋予0-5的数值：其中Ai为复杂度调整值，取值0-5)01.065.0(iAUFCFP)01.065.0(iATCF39功能点方法—技术复杂度因子40功能点方法—技术复杂度因子（续）复杂度调整表41功能点方法—技术复杂度因子（续）设前例中项复杂度调整项均为极其重要，即调整值全都是，则调整后的功能点为：514FP=27×(0.65+0.01×14×5)=36.45功能点方法—技术复杂度因子（续）总结：根据用户需求确定系统需求边界和软件必须具有的功能。确定每个功能的类型。评估每一个功能类型的复杂度，求和得到系统未调节功能点UFC。确定技术复杂度因子TCF。计算最终功能点数目FP。42功能点方法—实例例子4344功能点转化为工作量根据项目特性，查询相关资料将功能点转化为工作量（一般是代码行数）最为简单的方法：程序语言表格45范例：功能点计算（续）则该项目若用java2语言编写，查阅前表得java2的功能点置换为48行，则代码量为：若用C++语言编写，查阅前表得C++的功能点置换为53行，则代码量为：6.17494845.36LOC85.19315345.36LOC计划评审技术（PERT）较好的PERT估计技术是一种基于β分布和软件各部分单独估算的技术。计算步骤：（1）对于每个软件部分要产生3个规模估算量：·表示软件第i部分可能的最低规模·表示软件第i部分最可能的规模·表示软件第i部分可能的最高规模（2）利用下面公式计算每个部件的期望规模和方差46iaibim计划评审技术（PERT）（续）（3）计算总的软件规模E和标准差σ：4748项目估算报告移动协同服务支撑平台项目估算报告.doc规模估算到成本估算估算出软件项目的规模后，需要将其转换成人月数。在软件项目从规模估算到成本估算的转换过程中，首先要确定每个人月平均完成代码数量，即软件生产率。1、生产率数据的获取：（1）选择一些近期完成的项目，这些项目在规模、使用的语言、应用类型和团队开发经验等方面要和待完成的项目类似（2）获得各个项目的LOC数据，各个项目都要使用相同的设计方案（3）对于更改过的程序，记录更改代码所占比例，仅计算新增或更改部分的LOC的数量（4）计算投入到每个项目上的人员数量（5）计算各个项目的软件生产率，即LOC/PM，然后求平均值49规模估算到成本估算（续）2、软件生产率的影响因素IBM500多个System/370项目的数据中总结出的相关生产率因素，如下图：503、估算以表3.3的数据为例来说明生产率数据的估算：某软件组织根据历史数据已经确定开发中等规模的控制程序的生产率为300LOC/PM，则该组织开发中等规模语言程序的生产率为：300×（3.9/1.8）=650LOC/PM51规模估算到成本估算（续）专家判定专家根据自己的经验和对项目的理解对项目成本做出估算。（1）求中值或平均值（2）召开小组会议（3）Delphi法（德尔菲法）（4）WidebandDelphi技术5253专家判断—Delphi技术每位专家根据软件系统规格说明书进行估算协调员整理专家估算，给出平均期望值在此基础上各位专家进行再次估算以上过程可重复多次，直到专家评估值之差达到要求……54方法的使用说明该方法中各位专家没有交流的机会，可以避免专家之间的相互影响，有利于各位专家作出自己的判断但同样也堵塞了专家间交流的渠道，使得每人的意见局限于自己的考虑之中，无法做出全面的估计55类比估计该方法寻找已经完成的项目，这些项目与需要开发的新项目在许多特征上必须是类似的。通过比