Upload
druce
View
72
Download
0
Embed Size (px)
DESCRIPTION
软件项目管理. 第四章 软件项目成本管理. 本章内容提要. 软件项目规模成本的概念 成本估算 成本预算 成本控制. 第一节 软件项目规模成本的概念. 软件项目规模度量单位: LOC(Lines of Code) :源代码程序长度的测量 FP(Function Point) :系统功能数量的测量 软件项目工作量是指为了提供软件的功能而必须完成的软件工程任务量。其度量单位为: 人月、人天、人年:人在单位时间内完成的任务量. 为了确定工作量度量单位,可设定一个“标准程序员”,例如具有 15~18 个月开发经验的程序员。 - PowerPoint PPT Presentation
Citation preview
软件项目管理
第四章 软件项目成本管理
本章内容提要 软件项目规模成本的概念 成本估算 成本预算 成本控制
第一节 软件项目规模成本的概念 软件项目规模度量单位:
LOC(Lines of Code) :源代码程序长度的测量FP(Function Point) :系统功能数量的测量
软件项目工作量是指为了提供软件的功能而必须完成的软件工程任务量。其度量单位为:人月、人天、人年:人在单位时间内完成的任务
量
为了确定工作量度量单位,可设定一个“标准程序员”,例如具有 15~18 个月开发经验的程序员。
工作量与规模紧密相关,此外还与项目和产品特性(如复杂性)相关。
在不会引起混淆的情况下,工作量和规模这两个概念可不做区别。
软件项目成本
完成软件项目工作量相应付出的代价,即待开发软件项目所需要的资金。
人的劳动消耗所需要的代价是软件产品的主要成本。 成本一般采用货币单位来计算,如人民币、美元等。
工作量和成本的关系
工作量是成本的主要考虑因素,项目的工作量估算和成本估算常常同时进行。
如果确定了单位工作量的成本,则可根据项目工作量直接计算出项目成本。
例如:如果一个软件项目的工作量是 20 人月,而企业的人力成本参数是 2 万元 / 人月,则项目的成本是 40 万元。
本章内容提要 软件项目规模成本的概念 成本估算 成本预算 成本控制
引言 成本估算方法 一种实用的项目成本估算过程
第二节 成本估算
2.1 引言 成本估算是对完成项目所需费用的估计,它是项目
成本管理的核心。 成本估算可以有一些误差。估算结果可用一个范围
表示,例如 $10000±$1000 。 成本估算所依据的信息包括:项目需求和 WBS ,
资源要求、资源消耗率(资源单价)、项目进度规划、历史项目数据等。
项目成本的构成直接成本:与具体项目的开发直接相关的成本。
如人员的工资、外包外购成本等。又可细分为开发成本、管理成本、质量成本等。
间接成本:不归属于一个具体的项目,是企业的运营成本,分摊到各个项目中。如房租、水电、保安、税收、福利、培训,等等。
2.2 成本估算方法
代码行、功能点 类比估算法 参数估算法 专家估算法
代码行( LOC )
从软件程序量的角度定义项目规模。 要求功能分解足够详细。 有一定的经验数据(类比和经验方法)。 与具体的编程语言有关。
优点: 直观、准确(在有代码的情况下)、易于计算(可使用代码行统计工具)。
缺点:对代码行度量没有公认的标准定义。代码行数量依赖于所用的编程语言和个人的编程风格。
在项目早期 , 需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量。
代码行( LOC )
功能点( FP )
用系统的功能数量来测量其规模,与实现产品所使用的语言和技术没有关系。
对系统的外部功能和内部功能进行计数。 根据技术复杂度因子(权)对它们进行调整,产生
产品规模的度量结果。
功能点计算公式
FP =UFC*TCFUFC(Unadjusted Function Point Count)
未调整功能点计数TFC(Technical Complexity Factor)
技术复杂度因子
UFC 的计算方法
首先计算功能计数项,对以下五类元素计数:外部输入:由用户输入的面向应用的数据项。外部输出:向用户提供的输出数据项。外部查询:要求系统回答的交互式输入。外部接口文件:与其它系统的接口数据文件。内部文件:系统使用的内部固定文件。
UFC 的计算方法
然后对各功能计数项加权并求和,得到 UFC 。
功能计数项 复杂度权重简单 中等 复杂
外部输入 3 4 6
外部输出 4 5 7
外部查询 3 4 6
外部接口文件 5 7 10
内部文件 7 10 15
案例分析
某学院安装了一个工资系统,人事处要求创建一个子系统来分析每门课程的人力资源成本。要求该子系统提供查询每门课程人力资源成本的功能。每名教师所得工资的细节可以通过工资系统中的文件得到,教师花在教每门课上的小时数可通过一个基于计算机的计时表系统中的文件得到。该子系统将计算结果存放到由总会计系统读取的一个文件中,并产生一个报告,来显示每名教师每门课的课时数及这些课时数相应的成本。
案例分析
问题:计算该子系统的 UFC 。(子系统产生的报告复杂度为高,其它所有元素的复杂度均为中等)
案例分析
答案: UFC=1*7+1*4+3*7=32
功能计数项 计数 复杂度权重外部输入 无外部输出 报告 1 7
外部查询 1 4
外部接口文件 工资文件 1 ,计时表文件 1 ,计算结果文件 1
7
内部文件 无
TCF 的计算方法
技术复杂度影响因素F1 可靠的备份和恢复 F2 数据通信F3 分布式函数 F4 性能F5 大量使用的配置 F6 联机数据输入F7 操作简单性 F8 在线升级F9 复杂界面 F10 复杂数据处理F11 重复使用性 F12 安装简易性F13 多重站点 F14 易于修改
TCF=0.65+0.01(sum(Fi)) : Fi:0-5,TCF:0.65~1.35
TCF 的计算方法
每个技术复杂度影响因素的取值范围:
取值 对系统的影响0 不存在或者没有影响1 不显著的影响2 相当的影响3 平均的影响4 显著的影响5 强大的影响
案例分析
案例中技术复杂度影响因素的取值F1 可靠的备份和恢复 1 F2 数据通信 5
F3 分布式函数 0 F4 性能 3
F5 大量使用的配置 1 F6 联机数据输入 0
F7 操作简单性 1 F8 在线升级 0
F9 复杂界面 1 F10 复杂数据处理 4
F11 重复使用性 0 F12 安装简易性 3
F13 多重站点 0 F14 易于修改 3
sum(Fi)=22
TCF=0.65+0.01(sum(Fi))=0.65+0.01*22=0.87
该子系统的功能点为: FP=UFC*TCF=32*0.87=27.8
案例分析
功能点与代码行的转换
语言 代码行 /FP
Assembly 320
C 150
COBOL 105
FORTRAN 105
PASCAL 91
ADA 71
PL/1 65
PROLOG/LISP 64
SMALLTALK 21
SPREADSHEET 6
成本估算方法
代码行、功能点 类比估算法 参数估算法 专家估算法
类比估算法
也称为基于案例的推理,估算人员根据以往完成的类似项目(源案例)所消耗的总成本(或工作量),来推算将要开发的软件(目标案例)的总成本(或工作量)。
需提取项目的一些特性作为比较因子,如项目类型( MIS 系统、实时系统等)、编程语言、项目规模、开发人员数量、软件开发方法等。
在项目初期信息不足时(例如市场招标和合同签订)适于采用类比估算法。
该方法简单易行,花费少,但准确性差。
类比估算法
成本估算方法
代码行、功能点 类比估算法 参数估算法 专家估算法
参数估算法
使用项目特性参数建立经验估算模型来估算成本。 经验估算模型是通过对大量的项目历史数据进行统
计分析(如回归分析)而导出的。 经验估算模型提供对项目工作量的直接估计。 该方法简单,而且比较准确,但如果模型选择不当或提供的参数不准确,也会产生较大的偏差。
经验估算模型
模型形式: E=A+B*SC
E:以人月表示的工作量A,B,C:经验导出的系数S:主要的输入参数 (通常是 LOC,FP 等 )
面向 LOC 的:Walston-Felix(IBM) 模型 E= 5.2*(KLOC)^0.91Balley-Basili 模型 E=5.5+0.73*(KLOC)^1.16Boehm简单模型 E=3.2*(KLOC)^1.05Doty模型 E=5.288*(KLOC)^1.047
经验估算模型
面向 FP 的: Albrecht and Gaffney 模型E=-13.39+0.0545FP
Matson,BarnettE=585.7+15.12FP
经验估算模型
Walston-Felix(IBM) 模型
1977 年, IBM 的 Walston 和 Felix 提出了如下的估算公式: E = 5.2×L ^0.91 , L 是源代码行数 ( 以 KLOC 计 ) ,
E 是工作量(以 PM 计) D = 4.1×L ^ 0.36 , D 是项目持续时间 ( 以月计 )
S = 0.54×E ^ 0.6 , S 是人员需要量 ( 以人计 )
DOC = 49×L ^ 1.01 。 DOC 是文档数量 ( 以页计 )
COCOMO ( Constructive Cost model )
构造性成本模型,是世界上应用最广泛的参数型软件成本估计模型。
由 Barry Boehm 利用加利福尼亚的一个咨询公司的大量项目数据推导出的一个成本模型。该模型于 198
1 年首次发表,于 1994 年又推出了 COCOMO II 。
模型类别
基本 COCOMO
静态单变量模型。 中等 COCOMO
在基本模型基础上考虑各种影响因素(工作量驱动因子),调整模型。
高级 COCOMO
中等 COCOMO 模型基础上考虑软件工程中各个步骤的影响。
基本 COCOMO
E=a*(KLOC)exp(b)
E是项目的工作量(以人月计)KLOC 是软件产品的代码行数a、 b是依赖于项目自然属性的参数
基本 COCOMO 系数表
系统类型 a b
有机 2.4 1.05
半相连 3.0 1.12
嵌入式 3.6 1.20
系统类型
有机( Organic ) 各类应用程序,例如数据处理、科学计算等。受硬件的约束比较小,接口环境灵活;软件的规模不是很大。
嵌入式( Embeded ) 系统程序,例如实时处理、控制程序等。 在硬件和软件的严格约束条件下运行,对系统进行变更
的代价很高;软件的规模任意。 半相连( Semidetached )
介于上述两种系统之间。
基本 COCOMO举例
一个 33.3 KLOC 的软件开发项目,属于半相连型的项目,采用基本 COCOMO 进行工作量的估算:a=3.0 , b=1.12
E = 3.0* L ^1.12 = 3.0* 33.3 ^1.12 = 152 PM
中等 COCOMO
E=a(KLOC)exp(b)*工作量系数 工作量系数是根据成本驱动因子的打分计算得出,
是对公式的校正系数。
中等 COCOMO 系数表
系统类型 a b
有机 3.2 1.05
半相连 3.0 1.12
嵌入式 2.8 1.20
成本驱动因子
驱动因子类型 编码 成本驱动因子
产品属性
RELY 需要的软件可靠性DATA 数据库规模CPLX 产品复杂度
计算机属性
TIME 执行时间限制STOR 主存限制VIRT 操作系统变更的程度TURN 计算机恢复时间要求
成本驱动因子(续)
驱动因子类型 编码 成本驱动因子
人员属性
ACAP 分析员能力AEXP 应用经验PCAP 程序员能力VEXP 虚拟机(如操作系统)经验LEXP 编程语言经验
项目属性MODP 现代编程实践的使用TOOL 软件工具的使用SCED 需要的开发进度
工作量系数的计算 规定每个成本驱动因子的取值范围,将其取值划分
为非常低、低、正常、高、非常高等级别,每个级别对应一个值。例如,软件组织可以决定使用以下系数来评估分析员能力 (ACAP) 的影响:
非常低( very low ) 1.46
低( low ) 1.19
正常( nominal ) 1.00
高( hign ) 0.80
非常高( very hign) 0.71
当每个成本驱动因子 Fi 的值选定后,工作量系数的计算如下:
工作量系数 =F1*F2*…Fi…*Fn
工作量系数的计算
中等 COCOMO举例 一个 33.3 KLOC 的软件开发项目,属于半相连型的
项目,采用中等 COCOMO 进行工作量的估算: a=3.0 , b=1.12
工作量系数 =0.70*0.85*1……*1.15=1.09
E = 3.0* 33.3 ^1.12 ×1.09= 166 PM
高级(详细) COCOMO
考虑了各成本驱动因子对分析、设计等各项目阶段的影响。
成本估算方法
代码行、功能点 类比估算法 参数估算法 专家估算法
专家估算法
由多位对应用领域和开发环境有丰富经验的专家进行成本估算。
为避免单个专家产生偏见,尽量由多位专家进行估算,取得多个估算值,最后得出综合的估算值。
专家估算法 -Delphi
组织者发给每位专家一份软件系统的规格说明和一张记录估算值的表格,请他们估算。
专家详细研究软件规格说明后,对该软件提出 3 个工作量(或成本)的估算值:最小值 ai 最可能值mi
最大值 bi
组织者对专家的表格中的答复进行整理,计算每位专家的平均估算值 Ei=(ai+4mi + bi)/6 和总的平均值E=(E1 +E2+…+En)/n (n 表示 n 个专家 ) 。
组织专家无记名填表格,比较估算差,并查找原因。 如果各个专家的估算差异超出规定的范围(例如:
15% ),则需重复上述过程 ,最终可以获得一个多数专家共识的软件工作量(或成本)估计值。
专家估算法 -Delphi
专家估算法举例
某管理信息系统 - 专家估算专家 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(万元)
在项目初期(特别是合同阶段),项目的需求不很明确,且需要尽快得出成本估算结果,此时可采用类比估算法或专家估算法。
需求确定之后,开始规划项目时,可采用参数估算法。
在项目的实施阶段,特别是在发生变更时,需重新估算项目的成本,这时可采用参数估算法和专家估算法。
成本估算方法总结
2.3 一种实用的软件成本估算过程 该过程步骤如下:1. 对项目进行任务分解 :1,2,…,i,…,n
2. 估算每个任务的成本Ci
3.项目的直接成本=C1+C2+……+Ci+……+Cn4. 项目总估算成本= 直接成本+间接成本5. 项目总报价=项目总估算成本+风险利润
估算每个任务的成本
先估计任务的工作量 Ei (一般以人月为单位)。 然后估算任务成本 Ci= Ei*人力成本参数。
直接成本估算
直接成本的构成:开发成本、管理成本、质量成本 管理和质量成本的简易估算法:
开发工作量: Effort(Dev) 管理和质量工作量: Effort(Mgn)=a*Effort(Dev)
a为比例系数,可根据企业的具体情况而定,例如 20%--25%。
直接成本 = Effort(Dev) + a*Effort(Dev)
间接成本估算
根据企业具体的成本模型进行计算。 简易估算方法:
间接成本 =直接成本 *间接成本系数间接成本系数根据企业的具体情况而定,例如取0.3。
项目总估算成本
总估算成本 = 直接成本 + 间接成本 = 直接成本 + 直接成本 * 间接成本系数 = 直接成本 (1+ 间接成本系数 )
= 工作量 * 人力成本参数( 1+ 间接成本系数) 成本系数 = 人力成本参数 *( 1+ 间接成本系数) 总估算成本 = 工作量 *成本系数 例如:某项目的工作量是 40人月,成本系数为 2万元 /人
月,则项目的总估算成本为 40*2=80万元。
项目总报价
风险利润包括风险基金、项目税费和税后利润等。 风险利润 = 项目总估算成本 *a% a是利润系数,根据企业、项目的不同而不同。
项目总报价 =项目总估算成本 +项目总估算成本 *a%
=项目总估算成本( 1+a%)
2.4 成本估算的准确度
类型 准确度 说明
量级估算 :合同前Order of magnitude
-25~~+75% 概念和启动阶段,决策
预算估算 :合同期Budget
-10~~+25% 编制初步计划
确定性估算 :WBS后 Definitive
-5~~+10% 工作分解后的详细计划
估算不准确的原因
基础数据不足 估算对需求的敏感性 软件项目存在许多变更和不确定因素 缺乏有经验的估算人员 签约前后的不连贯
避免低劣的估算
留出估算的时间,并做好计划 注意积累项目数据,以开发人员提供的经验数据为基础进行估算
分类法估算 进行详细的较低层次上的估算 使用估算工具 使用几种不同估算技术,并比较它们的结果
估算的表达方式
加减限定表示 6 个人月的工作量可表示为 6+3 、 6-1 人月。 范围表示 6 个人月的工作量可表示为 5~9 人月。
估算的表达方式 风险量化
估算: 6 个人月, +3 , -2
+1 人月:延迟交付转换子系统
-1 人月:新成员的工作效率高
+1 人月:采用的新工具没有预计的好
-1 人月:采用的新工具比预计的好
+0.5 人月 : 员工病事假
+0.5 人月 : 低估规模
本章内容提要 软件项目规模成本的概念 成本估算 成本预算 成本控制
第三节 成本预算 成本预算是将项目总估算成本分摊到各个工作
单元中去,主要包括三个步骤: 将项目的总估算成本分摊到各项活动。根据项目的
成本估算确定项目的总预算成本后,将总预算成本按照项目工作分解结构( WBS )和每一项活动的工作范围,以一定比例分摊到各项活动中,为每项活动建立总预算成本。
将活动总预算成本分摊到工作包。将活动总预算成本按照构成这一活动的工作包和所消耗的资源数量进行成本预算分摊。
成本基线
0
5
10
15
20规
划
需求
设计
开发 -1 开发 -2 测试
验收
1 2 3 4 5 6 7( )时间 周
()
成本
万
成本基线
确定各工作包成本预算支出的时间以及每一个时间所发生的累积成本支出额,形成成本基线。
成本预算的依据和特征 成本预算的依据:
成本估算工作分解结构( WBS )项目进度计划
成本预算的特征:计划性:将总费用精确的分配到 WBS 的每一个
工作包中。控制性:合理规划资源,控制资源使用,节约成
本。
降低项目成本预算的方法
降低资源的费率 减少任务的工时 减少加班 替换资源 删除任务
降低资源的费率 降低人力资源的费率往往会打击工作人员的积极性,但可以通过降低其他资源的费率来实现,比如降低能源消耗、设备费用、耗材费用等。
减少任务的工时 使任务高效率地执行,避免浪费时间,从而适当减少任务的工时,可以降低任务的费用。
降低项目成本预算的方法
减少加班 加班需要支付加班费率,这通常要高于正常情
况下的人力资源费率,所以减少加班可以有效的减少项目成本。
替换资源 用廉价的资源替换比较高价的资源,但有一个前
提,那就是替换的资源同样能胜任这项任务。 删除任务 确认删除该任务对项目没有影响或影响在可控
制范围内才可采用。
降低项目成本预算的方法
重视维护阶段的成本预算
加强客户对软件维护在软件应用中重要性的认识。在签订软件合同时,应增加对软件维护的成本预算。
软件市场中对软件维护的规范性要有一个统一科学的认识和约束,要形成规范的软件服务市场。
坚持有偿服务的原则。 加强软件开发中的软件测试、软件复用,组件化,
标准化、泛性模式的运用。