1、成本管理的重要性成本管理的重要性美国斯坦迪什公司美国斯坦迪什公司19951995年的研究表明，年的研究表明，项目失败的真正原因，包括成本失控，项目失败的真正原因，包括成本失控，是没有很好的项目管理。是没有很好的项目管理。软件项目的成本可控吗？软件项目的成本可控吗？软件项目的成本控制实在太难，按项目预软件项目的成本控制实在太难，按项目预算几乎是不可能的。算几乎是不可能的。（1）需求不确定需求不确定项目工期不确定、费用无法控制；项目工期不确定、费用无法控制；（2）项目采用的技术先进，技术风险很大，因此，费用无）项目采用的技术先进，技术风险很大，因此，费用无法控制；法控制；（3）软件开发是一个人行为
2、，因此，人员的积极性、工作软件开发是一个人行为，因此，人员的积极性、工作效率、配合情况等，不像其他行业的项目那样，可以准效率、配合情况等，不像其他行业的项目那样，可以准确地预测。因此，工作效率无法确定；确地预测。因此，工作效率无法确定；（4）项目具有独特性，没有历史资料可以借鉴。因此，成项目具有独特性，没有历史资料可以借鉴。因此，成本估算带有很大的盲目性。本估算带有很大的盲目性。为了使公司和项目组的项目管理水平获得提升，项目经理首先要提高自己的认识能力和实际管理水平。本章主要内容：本章主要内容：3.1 3.1 概述概述3.2 3.2 软件规模估算软件规模估算3.3 3.3 软件项目成本估算软件
3、项目成本估算3.4 3.4 软件项目成本监控软件项目成本监控3.1概述概述成本的解释成本的解释)软件项目成本包含：软件项目成本包含：1.人力资源成本人力资源成本:工资、福利、招聘和培训等工资、福利、招聘和培训等成本费用。成本费用。2.软硬件资源成本软硬件资源成本：开发和测试工具、服开发和测试工具、服务器、网络设备等软硬件资源费用。务器、网络设备等软硬件资源费用。3.商务活动成本商务活动成本：差旅费、交通费：差旅费、交通费、接待费、通信费等。、接待费、通信费等。4.其他成本费用其他成本费用：未计入上述分类的成本费未计入上述分类的成本费用。用。为了评价项目成本的可确定程度再分别估计每个单独的开发任
4、务的成本，最后累加起来得出软件开发工程的总成本。计算赢得值(CEW或BCWP)目的：为什么要求出该估算值？COCOMO模型是按其详细程度分为三级：一种 预测未来事件的技术。软件项目估算不是一劳永逸的活动，而是随项目的进行而进行的一个逐步求精的过程。典型的WBS（Work BreakdownStructure）估计底层每一模块的规模，汇总以得到总体估计；等于计划工作量与预算单价的乘积之和。组织专家们召开小组会议进行讨论，统一某一估算值；估计底层每一模块的规模，汇总以得到总体估计；（2）项目采用的技术先进，技术风险很大，因此，费用无法控制；对于更改过的程序，记录更改代码所占比例Wideband D
5、elphi 技术常用的软件规模度量标准：典型的WBS（Work BreakdownStructure）帮助因素：典型的WBS（Work BreakdownStructure）成本管理目标是确保在批准的预算范围内完成项目所需的各项任务。等于已完成工作量与预算单价的乘积之和。根据是否可以直接用一种经济的方式识别和跟踪项目成本，软件项目成本可分为以上类型。软件项目成本管理活动包括：软件项目成本管理活动包括：软件系统规模估算软件系统规模估算软件项目成本估算软件项目成本估算软件项目成本预算制订软件项目成本预算制订软件项目成本监控软件项目成本监控成本管理目标是确保在批成本管理目标是确保在批准的准的预算范围
6、内预算范围内完成完成项目项目所需的各项任务。所需的各项任务。估算的时机估算的时机A.软件项目估算不是一劳永逸的活动，而软件项目估算不是一劳永逸的活动，而是随项目的进行而进行的一个是随项目的进行而进行的一个逐步求精逐步求精的过程。的过程。估算的时机估算的时机B.对任何一种估算方法来说，估算的时机和精对任何一种估算方法来说，估算的时机和精度都是一种度都是一种矛盾矛盾。图3.1 软件项目估算的时机估算的时机估算的时机C.选择合适的时间点进行估算是估算中必须考选择合适的时间点进行估算是估算中必须考虑的一个问题。因为估算本身也需要虑的一个问题。因为估算本身也需要成本成本。图3.2 软件项目估算时机软件产
7、品生命周期及需要进行估算的五个时间点：E1,E2,E3,E4,E5估算的时机估算的时机可行性论证：可行性论证：E1E1客户需求阶段列出客户需要的基本软件功能。时间点E1的估算可以为软件组织提供初步信息，否则需要重新考虑项目的可行性。估算的时机估算的时机需求分析：需求分析：E2 E2 产品定义阶段完成对项目的规格说明，进一步细化系统功能。此时估算有助于软件组织在进入产品开发前再次权衡产品的可行性估算的时机估算的时机系统设计：系统设计：E3E3系统设计阶段给出产品的完整软件体系结构和各个子系统及模块的说明。估算的时机估算的时机系统实现：系统实现：E4E4 设计通过审查之后，系统设计通过审查之后，系
8、统的实现工作就开始了。该的实现工作就开始了。该阶段结束时，前面各项活阶段结束时，前面各项活动中消耗的资源（时间及动中消耗的资源（时间及人力等）和软件工作量均人力等）和软件工作量均可获得，从而可对原有的可获得，从而可对原有的估算进行调整，后期需要估算进行调整，后期需要的工作则按此估算进行计的工作则按此估算进行计划。划。估算的时机估算的时机系统运行维护：系统运行维护：E5E5 当所有的工作都已完成当所有的工作都已完成并得到了验证后，系统并得到了验证后，系统就可以投入运行了。估就可以投入运行了。估算工作实际上是对估算算工作实际上是对估算过程的评价，即用实际过程的评价，即用实际的消耗与各个阶段估算的消
9、耗与各个阶段估算值进行比较，为下一项值进行比较，为下一项目积累宝贵的经验。目积累宝贵的经验。3.2软件项目规模估算软件项目规模估算常用的软件规模度量标准：L=Ck*K1/3*td4/3 其中：L-源代码行数(以LOC计)过紧的进度计划降低了计划的精确度创新点过多，不利于快速开发。按照模型中的变量依存关系没有系统的开发方法，缺乏文档和复审最好由多个专家进行估算。与产品层次有关（模块子系统-系统）收集实际成本(CAC)功能点FP是由未调整的功能点数UFC与技术复杂度因子（TCF）相成得到。估算应征求所有项目干系人的意见，并采用可靠的模型算法。成本估算是软件项目计划中的一种重要组成部分；软件项目成本
10、管理活动包括：代码行可分为：无注释的代码行（NCLOC）和注释的源代码行（CLOC）（2）项目采用的技术先进，技术风险很大，因此，费用无法控制；可用来管理后续成本工作，可用作项目绩效衡量标准。式中E为开发所需的人力（人/月）。常用的软件规模度量标准：FP=UFC*TCF项目变动时，可通过此过程识别变动并及时调整成本估算值。编码和单元测试(CUI)3.2软件项目规模估算软件项目规模估算工作分解结构工作分解结构WBS典型的典型的WBS（WorkBreakdownStructure）工作分解结构工作分解结构WBS常用的软件规模度量标准：常用的软件规模度量标准：1.代码行代码行LOC2.功能点功能点F
11、P工作分解结构工作分解结构WBS软件规模的估计步骤：软件规模的估计步骤：1.在技术允许的条件下，应从最详细的在技术允许的条件下，应从最详细的WBS开开始；始；2.精确定义度量的标准；精确定义度量的标准；3.估计底层每一模块的规模，汇总以得到估计底层每一模块的规模，汇总以得到总体估计；总体估计；4.适当考虑偶然因素的影响。适当考虑偶然因素的影响。WBS越细，对软件规模的估计就越准确。越细，对软件规模的估计就越准确。代码行：代码行：代码行代码行LOC是常用的源代码程序长度的度是常用的源代码程序长度的度量标准。量标准。代码行可分为：无注释的代码行（代码行可分为：无注释的代码行（NCLOC）和注释的源
12、代码行（）和注释的源代码行（CLOC）实际工作中，也常常使用实际工作中，也常常使用KLOC（千代码（千代码行）来表示程序长度。行）来表示程序长度。一代码行（一代码行（1LOC）价值和人月均代码行数）价值和人月均代码行数可以体现一个软件生产组织的生产能力。可以体现一个软件生产组织的生产能力。由由IBM工程师工程师A.J.Albrecht于于79年首次提出年首次提出;是基于系统功能的一种规模估计方法，是基于系统功能的一种规模估计方法，FP法法将信息系统抽象成输入数据、输出数据、查询将信息系统抽象成输入数据、输出数据、查询数据、系统内部文件及系统外部文件数据、系统内部文件及系统外部文件计算未调整的功
13、能点数计算未调整的功能点数UFCUFC的步骤的步骤UFCUFC：Unadjusted Function Point CountUnadjusted Function Point Count（1）计算所需要的输入、输出、计算所需要的输入、输出、查询、外部文件、内部文件的数查询、外部文件、内部文件的数量。量。计算功能点数的步骤：计算功能点数的步骤：功能项权 重简单一般复杂输入346输出457查询346外部文件71015内部文件5710（2）判断项目复杂性，计算判断项目复杂性，计算UFC由估计人员对项目的复杂性作出判断，分成简单、由估计人员对项目的复杂性作出判断，分成简单、一般、复杂三种情况。然后根
14、据下表求出功能项的一般、复杂三种情况。然后根据下表求出功能项的加权和。加权和。功能点功能点FP是由未调整的功能点数是由未调整的功能点数UFC与技术复杂度因子（与技术复杂度因子（TCF）相成得到。）相成得到。计算功能点数的步骤：计算功能点数的步骤：从上表计算出：从上表计算出：TCF=0.65+0.01*(SUM(Aj)TCF的取值范围为的取值范围为0.651.35，分别对应着组成部分分别对应着组成部分Aj都取值都取值0和和5，得到功能点得到功能点FP的计算公式：的计算公式：FP=UFC*TCFFP有助于在软件项目的早期作出规有助于在软件项目的早期作出规模估计，但无法自动度量。模估计，但无法自动度
15、量。常用做法：早期估计时用常用做法：早期估计时用FP，再依，再依据经验将据经验将FP转化为转化为LOC,再使用再使用LOC继续进行估计继续进行估计。假定：如果资源具备的话，在什么条件下承诺交付该估算值？项目预算和计划（CBC)EAF根据引入的15个成本驱动量计算，（见表3.EAF根据引入的15个成本驱动量计算，（见表3.36，D是项目持续时间(以月计)不仅仅是简单的数字，而是资源、成本估算和预算分解说明的有机结合。获得各个项目的LOC数据，各项目都使用相同的计数方案此时估算有助于软件组织在进入产品开发前再次权衡产品的可行性并以此预测项目可能的完工时间和完工时的可能费用。它是假定在软件开发的整个
16、生存期中工作量有特定的分布。原计划 为一年，而实际情况为五年。累计计划成本额（BCWS:Budgeted Cost of Work Scheduled):某一时点已经完成的工作所实际花费成本的总金额。可用来管理后续成本工作，可用作项目绩效衡量标准。过程：如何进行该工作，采用哪些成本估算工具和技术？某一时点应当完成的工作所需投入资金或花费成本的累计值。S为以KLOC计数的程序规模，a、b、c、d是指不同软件开发方式的经验值。进度:D=c*(E)d各程序设计语言中实现一个功能点所需的代码行数的粗略估算(LOC/FP)帐篷中的高杆现象：高杆部分占据大部分成本式中E为开发所需的人力（人/月）。因此，工
17、作效率无法确定；CV也是衡量成本绩效的指标。如“快速”是不可检验，“响应时间不超过xx秒”是可检验的。式中E为开发所需的人力（人/月）。Visual Basic1978年Putnam提出的模型，是一种动态多变量模型。最好由多个专家进行估算。01*(SUM(Aj)组织专家们召开小组会议进行讨论，统一某一估算值；估算应征求所有项目干系人的意见，并采用可靠的模型算法。COCOMO模型（基本、中级、详细）L=Ck*K1/3*td4/3 其中：L-源代码行数(以LOC计)可用来管理后续成本工作，可用作项目绩效衡量标准。是反映了满足质量标准的工作实际进度和工作绩效，体现了投资额到项目成果的转化。协调员给每
18、位专家一份软件规格说明书和一张记录估算值 的表格;详细COCOMO模型中名义工作量aSb估算公式与开发时间的计算公式和中级COCOMO模型相同，详细COCOMO模型中名义工作量aSb估算公式与开发时间的计算公式和中级COCOMO模型相同，L是用作预测量的LOC，E是以人有为单位的工作量，DOC是以页数为单位的文本量，D是以月为单位的所需时间。好处：去掉一些极端偏颇无知的估算得到功能点FP的计算公式：原计划 为一年，而实际情况为五年。功能点度量在以下情况下特别有用：功能点度量在以下情况下特别有用：（1）估计新的软件开发项目；）估计新的软件开发项目；（2）应用软件包括很多输入输出或文件活动；）应用
19、软件包括很多输入输出或文件活动；（3）拥有经验丰富的功能点估计专家；）拥有经验丰富的功能点估计专家；（4）拥有充分的数据资料，可以相当准确地将功）拥有充分的数据资料，可以相当准确地将功能点转化为能点转化为LOC。各程序设计语言中实现一个功能点所需各程序设计语言中实现一个功能点所需的代码行数的粗略估算的代码行数的粗略估算(LOC/FP)程序设计语言平均值中值低值高值C16210933704C+665329178Java635377-SQL40377110Visual Basic474216158计划评审技术计划评审技术(ProgramEvaluationandReviewTechnique，PE
20、RT)是是20世纪世纪50年年代末开发的用于项目进度规划的代末开发的用于项目进度规划的一种一种技术。后将其引入到软件技术。后将其引入到软件规模估计的应用中。规模估计的应用中。公式见书公式见书P853.3软件项目成本估算软件项目成本估算软件生产率估算软件生产率估算1.生产率数据的获取生产率数据的获取 选择一些最近完成的项目，要和等完成项选择一些最近完成的项目，要和等完成项目相似。目相似。获得各个项目的获得各个项目的LOC数数据据，各项目都使用，各项目都使用相同的计数方案相同的计数方案 对于更改过的程序，记录更改代码所占比对于更改过的程序，记录更改代码所占比例例 计算投入到每个项目的人员数量计算投
21、入到每个项目的人员数量 计算各个项目的软件生产率即计算各个项目的软件生产率即LOC/PM,进进而求出平均值。而求出平均值。软件生产率估算软件生产率估算2.影响因素影响因素 需要大量的历史数据为基础，需要大量的历史数据为基础，可以借公开的数据作参考，对比自可以借公开的数据作参考，对比自己的数据，以确定自身己的数据，以确定自身生产率。生产率。软件生产率估算软件生产率估算3.估算估算 可以根据历史数据比如表中数据可以根据历史数据比如表中数据进行生产率数据的估算进行生产率数据的估算 成本估算是软件项目计划中的一种重要组成部分；成本估算目标是要完成软件项目所需费用的估计和计划。成本估算是在无法以高可靠性
22、预计的环境下进行的。根据历史数据进行估算-理想状况一一.专家判定专家判定由专家根据经验和对项目的理解对项目由专家根据经验和对项目的理解对项目进行成本估算。进行成本估算。最好由多个专家进行估算。最好由多个专家进行估算。对于由多个专家得到的多个估算值合成对于由多个专家得到的多个估算值合成一个最终的估算值。可采用的方法有：一个最终的估算值。可采用的方法有：求中值或平均值求中值或平均值 召开小组会议召开小组会议 Delphi技术技术 WidebandDelphi技术技术一一.专家判定专家判定1.求中值或平均值求中值或平均值 方法简单，但易于受到极端估算方法简单，但易于受到极端估算值的影响而造成偏差。值
23、的影响而造成偏差。一一.专家判定专家判定2.召开小组会议召开小组会议 组织专家们召开小组会议进行讨组织专家们召开小组会议进行讨论，统一某一估算值；论，统一某一估算值；好处：去掉一些极端偏颇无知的好处：去掉一些极端偏颇无知的估算估算 不利：易受权威人士或能言善辩不利：易受权威人士或能言善辩人士影响人士影响一一.专家判定专家判定3.Delphi技术技术 一种一种预测未来事件的技术。预测未来事件的技术。作为一种使专家意见一致的方法。作为一种使专家意见一致的方法。一一.专家判定专家判定3.Delphi技术技术步骤：步骤：协调员给每位专家一份协调员给每位专家一份软件规格说明软件规格说明书书和一张和一张记
24、录估算值记录估算值的表格的表格;专家无记名填写表格，相互间不能讨专家无记名填写表格，相互间不能讨论；论；协调员对专家填协调员对专家填在表上的估算进行小在表上的估算进行小结，给出结，给出估算迭代表估算迭代表，要求专家进行，要求专家进行下一轮估算。下一轮估算。专家重新无记名填专家重新无记名填表。表。一一.专家判定专家判定3.Delphi技术技术图3.4 Delphi成本估算迭代表的样例这种模型是依据在一些大型项目（总工作量达到或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。Albrecht于79年首次提出;根据成本估算值而做的承诺程度。成本、进度绩效(C
25、PI、CV)专家开会讨论软件产品和任何与估算相关的问题要保留以往完成项目的历史记录。完成软件需求说明书从不可检验到可检验的转化，需要许多工作量。高层的决定不总是对的，需要和专家、项目组成员共同协商。L是用作输入的预测量，这些困难会使成本上升，有时会遗漏开发软件中的某些部分。对于非机器指令编写的源程序，如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。软件项目估算不是一劳永逸的活动，而是随项目的进行而进行的一个逐步求精的过程。在项目开始之前，必须先为在整个项目工期内如何和何时使用资金作出预算和计划。Ck-技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环境而异.对软件项目的认可程
26、度；项目变动时，可通过此过程识别变动并及时调整成本估算值。L是用作预测量的LOC，E是以人有为单位的工作量，DOC是以页数为单位的文本量，D是以月为单位的所需时间。赢得值是整个项目期间必须的重要参数2 软件项目估算时机它是假定在软件开发的整个生存期中工作量有特定的分布。WBS、FP、LOC、PERT为了使公司和项目组的项目管理水平获得提升，项目经理首先要提高自己的认识能力和实际管理水平。一一.专家判定专家判定4.WidebandDelphi技术技术将小组讨论与将小组讨论与Delphi技术结合起来：技术结合起来：给每位专家发一份软件规格说明书和一张记录估给每位专家发一份软件规格说明书和一张记录估
27、算值算值的表格的表格;专家开会讨论软件产品和任何与估算相关的问题专家开会讨论软件产品和任何与估算相关的问题专家无记名填写表格；专家无记名填写表格；协调员对专家填协调员对专家填在表上的估算进行小结，给出在表上的估算进行小结，给出估估算迭代表算迭代表，要求专家进行下一轮估算。，要求专家进行下一轮估算。专家召开小组会议讨论上次估计结果，自愿修改专家召开小组会议讨论上次估计结果，自愿修改个人估计。个人估计。一一.专家判定专家判定4.WidebandDelphi技术技术将小组讨论与将小组讨论与Delphi技术结合起来：技术结合起来：二二.类比类比把当前项目和以前做过的类似项目把当前项目和以前做过的类似项
28、目比较，获得其工作量的估算值。比较，获得其工作量的估算值。要保留以往完成项目的历史记录。要保留以往完成项目的历史记录。基本步骤是：基本步骤是：1.整理出项目功能列表和实现每个功能的代码行；整理出项目功能列表和实现每个功能的代码行；2.标识出每个功能列表与历史项目的相同点和不同点，特别要标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；注意历史项目做得不够的地方；3.通过步骤通过步骤1和和2得出各个功能的估计值；得出各个功能的估计值；4.产生规模估计。产生规模估计。三三.自顶向下自顶向下推算出项目的总体成本或工作量，然后推算出项目的总体成本或工作量，然后按比例分配到
29、各个组成部分中去。按比例分配到各个组成部分中去。优点：对系统级的重视，一般不会遗漏优点：对系统级的重视，一般不会遗漏系统级事务的成本。如系统集成、用户系统级事务的成本。如系统集成、用户手册、配置管理等。手册、配置管理等。其缺点是难以识别较低级别上的技术性其缺点是难以识别较低级别上的技术性困难。这些困难会使成本上升，有时会困难。这些困难会使成本上升，有时会遗漏开发软件中的某些部分。遗漏开发软件中的某些部分。三三.自顶向下自顶向下任务分解技术任务分解技术首先把软件开发工程分解为若干个相首先把软件开发工程分解为若干个相对独立的任务。再分别估计每个单独对独立的任务。再分别估计每个单独的开发任务的成本，
30、最后累加起来得的开发任务的成本，最后累加起来得出软件开发工程的总成本。出软件开发工程的总成本。估计每个任务的成本时，通常先估计估计每个任务的成本时，通常先估计完成该项任务需要用的人力完成该项任务需要用的人力(以人月为以人月为单位单位)，再乘以每人每月的平均工资而，再乘以每人每月的平均工资而得出每个任务的成本。得出每个任务的成本。482023-1-24四四.自底向上自底向上自底向上估算是把待开发的软自底向上估算是把待开发的软件逐步细化，直到能明确工作量件逐步细化，直到能明确工作量，由负责该部分的人给出工作量，由负责该部分的人给出工作量的估算值，然后把所有部分相加的估算值，然后把所有部分相加，就得
31、到了软件开发的总工作量，就得到了软件开发的总工作量。每个部分的估算较精确。每个部分的估算较精确。易于忽略许多与软件开发有关的易于忽略许多与软件开发有关的系统级成本。总估算值偏低。系统级成本。总估算值偏低。花费的精力更多。花费的精力更多。四四.自底向上自底向上任务单元法，最常见的一种方法。任务单元法，最常见的一种方法。五五算法模型算法模型经验模型容易受主观因素的影响经验模型容易受主观因素的影响。采用数学方法建立正式的模型是采用数学方法建立正式的模型是必需的。必需的。五五算法模型算法模型按照模型中的变量依存关系按照模型中的变量依存关系静态模型静态模型动态模型动态模型按照变量的多少，按照变量的多少，
32、单变量模型单变量模型多变量模型多变量模型静态单变量模型静态单变量模型用同一个基本公式通过同一个用同一个基本公式通过同一个预测量来估算所需要的值。常见预测量来估算所需要的值。常见公式：公式：其中其中C是待估算的量，是待估算的量，L是用作输入的预测量，是用作输入的预测量，a,b是经验参数是经验参数静态单变量模型静态单变量模型马里兰大学软件工程实验室所马里兰大学软件工程实验室所建立的建立的SEI模型模型公式：公式：L是用作预测量的是用作预测量的LOC，E是以人是以人有为单位的工作量，有为单位的工作量，DOC是以页是以页数为单位的文本量，数为单位的文本量，D是以月为单是以月为单位的所需时间位的所需时间
33、。静态多变量模型静态多变量模型基于静态单变量模型，但还取基于静态单变量模型，但还取决于几个能代表软件开发环境的决于几个能代表软件开发环境的各种各种因素的变量，如软件开发因素的变量，如软件开发方法、用户需求变化情况等。方法、用户需求变化情况等。如如COCOMO模型，模型，动态多变量模型动态多变量模型Putnam模型就是一个动态多变模型就是一个动态多变量模型，见后面部分。量模型，见后面部分。其他模型其他模型对以前的软件项目中收集到的对以前的软件项目中收集到的数据进行回归分析而建立的模型数据进行回归分析而建立的模型，其结构如下：，其结构如下：其中，其中，A、B、C是由经验估计是由经验估计的常数，的常
34、数，E是以人月为单位的工是以人月为单位的工作量，作量，X是预测变量，通常是是预测变量，通常是LOC和和FP两种方式。两种方式。其他模型其他模型当预测量是当预测量是LOC时时，估算模型有：，估算模型有：当预测量是当预测量是FP时，估算模型有：时，估算模型有：IBM估算模型估算模型 1977年，年，IBM的的Walston和和Felix提出了如下的估算公提出了如下的估算公式：式：E5.2L0.91，L是源代码行数是源代码行数(以以KLOC计计)，E是是工作量（以工作量（以PM计）计）D4.1L0.36，D是项目持续时间是项目持续时间(以月计以月计)S0.54E0.6，S是人员需要量是人员需要量(以
35、人计以人计)DOC49L1.01。DOC是文档数量是文档数量(以页计以页计)在此模型中，一般指一条机器指令为一行源代码。在此模型中，一般指一条机器指令为一行源代码。一个软件的源代码行数不包括程序注一个软件的源代码行数不包括程序注释、作业命令、释、作业命令、调试程序在内。对于非机器指令编写的源程序，如汇调试程序在内。对于非机器指令编写的源程序，如汇编语言或高级语言程序，编语言或高级语言程序，应转换成机器指令源代码行应转换成机器指令源代码行数来考虑。数来考虑。COCOMO估算模型估算模型基本基本COCOMO模型估算公式：模型估算公式：工作量工作量:E=a*(KLOC)b进度进度:D=c*(E)d式
36、中式中E为开发所需的人力（人为开发所需的人力（人/月）。月）。D为所为所需的开发时间（月）。需的开发时间（月）。KLOC为估计提交的千为估计提交的千代码行。代码行。a、b、c和和d是指不同软件开发方式的经验是指不同软件开发方式的经验值。值。由TRW公司开发，Boehm提出的结构化成本估算模型（Constructive Cost Mode）是最精确、最易于使用的成本估算方法之一。中级中级COCOMO模型模型 中级中级COCOMO模型估算公式：模型估算公式：式中E为开发所需的人力（人/月）。S为以KLOC计数的程序规模，EAF是工作量调整因子是工作量调整因子，a、b、c、d是指不同软件开发方式的经
37、验值。其中aSb是名义工作量名义工作量。EAF根据引入的15个成本驱动量计算，（见表3.10 ），将15个评分值相乘即可获得EAF.进度:D=c*(E)d中级中级COCOMO模型模型EAF根据引入的15个成本驱动量计算，（见表3.10 ），将15个评分值相乘即可获得EAF.EAF根据引入的15个成本驱动量计算，（见表3.在技术允许的条件下，应从最详细的WBS开始；WBS、FP、LOC、PERT常用的软件规模度量标准：这些困难会使成本上升，有时会遗漏开发软件中的某些部分。可用来管理后续成本工作，可用作项目绩效衡量标准。典型的WBS（Work BreakdownStructure）其他成本费用：未
38、计入上述分类的成本费用。赢得值法是监视和报告项目进展情况的必要工具。功能点度量在以下情况下特别有用：Micorsoft Word for Windows 1.成本、进度绩效(CPI、CV)对软件项目的认可程度；（2）应用软件包括很多输入输出或文件活动；UFC：Unadjusted Function Point Count软件需求对估算很重要。比较后，可以改进成本驱动因子，提高估算精度，改进估算技术。1978年Putnam提出的模型，是一种动态多变量模型。L是用作预测量的LOC，E是以人有为单位的工作量，DOC是以页数为单位的文本量，D是以月为单位的所需时间。赢得值法是一种 能全面衡量项目成本、
39、进度的整体方法；典型的WBS（Work BreakdownStructure）详细详细COCOMO模型模型详细COCOMO模型中名义工作量名义工作量aSb估算公式与开发时间的计算公式和中级COCOMO模型相同，相同，式中E为开发所需的人力（人/月）。S为以KLOC计数的程序规模，a、b、c、d是指不同软件开发方式的经验值。其不同之处其不同之处在于成本驱动因素的获取方式，（见表3.11-3.13）这些成本驱动因素与下列方面有关：1.与产品层次有关（模块子系统-系统）2.与软件开发阶段有关：需求计划和产品设计(RPD)详细设计(DD)编码和单元测试(CUI)集成测试(IT)进度:D=c*(E)d详
40、细详细COCOMO模型模型详细详细COCOMO模型模型详细详细COCOMO模型模型COCOMO模型总结模型总结COCOMO模型是按其详细程度详细程度分为三级：基本COCOMO模型中级COCOMO模型详细COCOMO模型基本COCOMO模型是是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。详细COCOMO模型包括中级COCOMO模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。70Putnam估算模型估算
41、模型 1978年年Putnam提出的模型，是一种动态多变量模型。提出的模型，是一种动态多变量模型。L=Ck*K1/3*td4/3其中：其中：L-源代码行数(以LOC计)K-整个开发过程所花费的工作量（以人年计）td-开发持续时间（以年计）Ck-技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环境而异.Ck的典型值 开发环境 开发环境举例 2000 差 没有系统的开发方法，缺乏文档和复审 8000 好 有合适的系统的开发方法，有充分的文档和复审 11000 优 有自动的开发工具和技术 它是假定在软件开发的整个生存期中工作量有特定的分布。这种模型是依据在一些大型项目（总工作量达到或超过30个
42、人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。Putnam模型可以导出一个“软件方程”，把已交付的源代码（源语句）行数与工作量和开发时间联系起来。1，建立成本估算目标建立成本估算目标在软件成本估算中，有时耗费大量精力收集的用于估算的信息项,在进行估算时却因为与估算需要关系不在而不被使用,因而大量的艰难工作和细致分析付之东流。因此，要先建立成本估算目标，先建立成本估算目标，以此来制定以后工作的详细程度。1.建立成本估算目标2.规划需要的数据和资源3.确定软件需求4.拟定可行的细节5.运用多种 独立的技术和原始资料6.比较并迭代各个估算值7.随访跟踪1，建立成本估
43、算目标建立成本估算目标帮助因素帮助因素：软件项目当前所处的软件项目当前所处的生命周期生命周期阶段阶段，它大致对应于，它大致对应于对软件项目的认可程度；对软件项目的认可程度；根据成本估算值而做的承诺程度。根据成本估算值而做的承诺程度。1，建立成本估算目标建立成本估算目标 软件项目在生命周期阶段的估算范围1，建立成本估算目标建立成本估算目标为了决策需要，有时还要作出为了决策需要，有时还要作出乐乐观观和和悲观悲观估算，然后在随后的工估算，然后在随后的工作中逐步调整。作中逐步调整。2、规划需要的数据和资源规划需要的数据和资源 为了避免出现因准备不充分而导致作出不可变更的软件承诺，我们可以将软件成本估算
44、看成一个小型项目，制定一份项目规划，可包括如下内容：目的：目的：为什么要求出该估算值？产品和进度：产品和进度：何时提供何种产品？责任：责任：每种产品由何人负责？过程：过程：如何进行该工作，采用哪些成本估算工具和技术？需要的资源：需要的资源：完成该工作需要多少数据、时间、费用及工作量等？假定：假定：如果资源具备的话，在什么条件下承诺交付该估算值？3、确定软件需求、确定软件需求软件需求对估算很重要。软件需求对估算很重要。软件需求说明书的价值由它可检验的程度决定软件需求说明书的价值由它可检验的程度决定的，可检验性越好，则价值越高。的，可检验性越好，则价值越高。如如“快速快速”是是不可检验，不可检验，
45、“响应时间不超过响应时间不超过xx秒秒”是可检验的。是可检验的。完成软件需求说明书从不可检验到可检验的转完成软件需求说明书从不可检验到可检验的转化，需要许多工作量。化，需要许多工作量。4、拟定可行的细节、拟定可行的细节考察越细，对软件开发技术理解考察越细，对软件开发技术理解得就越透彻。得就越透彻。在估算时把软件分得越细，软件在估算时把软件分得越细，软件模块的个数越多，总的误差就减模块的个数越多，总的误差就减少。少。对软件必须执行的功能考虑得越对软件必须执行的功能考虑得越多，遗漏某些次要成本的可能性多，遗漏某些次要成本的可能性就越小。就越小。5、运用多种运用多种 独立的技术和原始资料独立的技术和
46、原始资料软件成本估算方法有多种，专家判定、类比、自顶向下、自底向上、算法模型等，这些方法各有优缺点，没有一种方法能在所有方面胜过其它技术。因此综合运用综合运用这些方法很重要。6、比较并迭代各个估算值、比较并迭代各个估算值综合运用各种估算方法的目的在于将各估算值进行比较比较，分析得到不同估算值的原因，从而找出可以改进改进估算的地方，提高提高估算的准确度准确度。估算值迭代的原因：乐观和悲观现象：选择合理的软件估算人员帐篷中的高杆现象：高杆部分占据大部分成本l对突出部分进行更加详细的考虑和迭代。l规模大-复杂度l复杂度-最难实现部分的复杂度7、随访跟踪、随访跟踪原因是：软件成本估算的输入和相应技术是
47、不完善的。比较后，可以改进成本驱动因子，提高估算精度，改进估算技术。确认有些项目确实不符合估算模型，有利于类似项目成本估算的有效性和模型改进。项目变动时，可通过此过程识别变动并及时调整成本估算值。当估算技术不能反映当前项目的实际情况时，需要将新项目中出现的新技术或方法等结合到改进的估算值和估算技术中。制订制订软件项目预算要将项目成本估软件项目预算要将项目成本估算分配到各个工作项，工作项算分配到各个工作项，工作项是以是以WBS为基础的。为基础的。成本预算过程的输出之一是项成本预算过程的输出之一是项目成本预算计划。可用来管理目成本预算计划。可用来管理后续成本工作，可用作项目绩后续成本工作，可用作项
48、目绩效衡量标准。效衡量标准。制订制订在制订软件项目成本预算时要注意：在制订软件项目成本预算时要注意：资源计划的匹配资源计划的匹配l 资源计划由项目经理制订资源计划由项目经理制订l 要与要与WBS等相对应，以保证预算的全面性和等相对应，以保证预算的全面性和有效性有效性预算的全面性预算的全面性l 不要漏算不要漏算预算的综合性预算的综合性l 不仅仅是简单的数字，而是资源、成本估算不仅仅是简单的数字，而是资源、成本估算和预算分解说明的有机结合。和预算分解说明的有机结合。MicorsoftWordforWindows1.0开发开发原计划原计划为为一年，而实际情况为五年。一年，而实际情况为五年。图3.9
49、项目估算所需的天数MicorsoftWordforWindows1.0开发延迟开发延迟原因：原因：1.项目初期制订的开发目标是不可实现的项目初期制订的开发目标是不可实现的 用最快的速度开发最好的字处理软件，12个月完成。2.过紧的进度计划降低了计划的精确度过紧的进度计划降低了计划的精确度3.创新点过多，不利于快速开发。创新点过多，不利于快速开发。一个目标都很困难，更不用说要同时完成两个人员不稳定，且因为任务紧，代码质量低不完整，造成维护软件稳定性上超期。启示：启示：估算应征求所有项目干系人的意见，估算应征求所有项目干系人的意见，并采用可靠的模型算法。并采用可靠的模型算法。高层的决定不总是对的，
50、需要和专家高层的决定不总是对的，需要和专家、项目组成员共同协商。、项目组成员共同协商。3.4软件项目监控软件项目监控3.4软件项目监控软件项目监控软件项目成本控制包括软件项目成本控制包括监控监控成本预算执行状况，确保正成本预算执行状况，确保正在执行的预算计划是有效的，在执行的预算计划是有效的，对于不合适的计划进行对于不合适的计划进行修改变更修改变更后后及时通知及时通知项目干系人等。项目干系人等。1.项目成本估算不准确项目成本估算不准确2.预算不详细预算不详细3.成本预算变更不及时成本预算变更不及时项目成本监控的目的是确保项目成项目成本监控的目的是确保项目成本管理规范行到执行，项目干系人本管理规
