「软件项目管理」一文详解软件项目成本计划

简介: 该文章详细解释了软件项目成本估算的过程与方法,涵盖了代码行估算法、功能点估算法、用例点估算法、类比估算法、自下而上估算法、参数模型估算法及专家估算法等多种技术,并探讨了成本预算的制定步骤。

封面

序言

大家都知道,软件项目管理包含项目初始、项目计划、项目执行控制和项目结束这四大模块。其中,项目计划包含范围计划、成本计划、时间计划等9大计划。

那在今天的文章中,就带大家来了解项目计划中的成本计划。

叮,开始学习吧~🎩

一、成本估算的定义

  • 成本估算是成本管理的核心,是预测开发一个软件系统所需要的总工作量的过程

  • 软件项目成本是指软件开发过程中所花费的工作量及相应的代价

  • 成本估算应该以软件项目管理、分析、设计、编程、测试等过程所花费的代价作为依据

  • 成本估算贯穿于软件的生命周期

二、估算的基本概念

1、关于估算

  • 估算不是很准确,会有误差
  • 项目经验数据非常重要;
  • 不要太迷信某些数学模型。

2、软件项目规模

  • 软件项目规模即工作量
  • 例如:软件规划,软件管理,需求,设计,编码,测试,以及后期的维护等任务。

3、软件规模单位

  • LOC (Line of Code) → 表示源代码长度的测量;
  • FP (Function Point) → 用系统的功能数量来测量;
  • 人月;
  • 人天;
  • 人年。

4、软件项目成本

  • 完成软件规模相应付出的代价
  • 待开发的软件项目需要的资金
  • 人的劳动的消耗所需要的代价是软件产品的主要成本

5、成本单位

成本单位通常是各种货币单位比如:

  • 人民币元
  • 美元
  • 英镑
  • ……

6、软件规模和软件成本的关系

  • 规模是成本的主要因素,是成本估算的基础
  • 有了规模就确定了成本。

7、成本估算结果

直接成本:具体项目相关的成本(如:人员工资、材料费、外包外购成本等)

间接成本: 可以分摊到各个具体项目中的成本(如:培训、房租水电、员工福利、市场费用、管理费、其他等等)

三、成本估算过程

1、估算输入

需求、资源要求、资源消耗率、进度规划、历史项目数据、学习曲线等

2、估算处理

采用一定的估算方法进行,包含直接成本间接成本的估算。

3、估算输出

简略详细的形式表示,对项目所需的所有资源的成本均需要加以估计。

四、成本估算方法

1、代码行估算法

(1)定义

  • 从软件程序量的角度定义项目规模。
  • 与具体的编程语言有关。
  • 分解足够详细。
  • 有一定的经验数据(类比和经验方法)。

(2)代码行估算的优点

代码是所有软件开发项目都有的“产品”,而且很容易计算代码行数。

(3)代码行估算的缺点

  • 对代码行没有公认的可接受的标准定义
  • 代码行数量依赖于所用的编程语言和个人的编程风格
  • 在项目早期、需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量。
  • 代码行强调编码的工作量,只是项目实现阶段的一部分。

2、功能点估算法(重点)

(1)定义

  • 实现的语言和技术没有关系;
  • 用系统的功能数量来测量其规模;
  • 通过评估、加权、量化得出功能点。

(2)功能点公式

  • FP = UFC * TCF
  • UFC:未调整功能点计数
  • TCF:技术复杂度因子

(3)UFC-未调整功能点计数

从处理逻辑的角度出发, UFC 可以分为 5功能计数项分别是:

  • 外部输入
  • 外部输出
  • 外部查询
  • 外部接口文件
  • 内部逻辑文件

接下来我们将依据这 5 个功能计数项进行详细细述。

(4)功能计数项详述

1)外部输入(External Inputs:EI)

软件提供面向应用的数据的项(如屏幕、表单、对话框、控件,文件等);在这个过程中,数据穿越外部边界进入到系统内部。 如下图所示:

外部输入

2)外部输出(External Outputs:EO)

向用户提供(经过处理的)面向应用的信息,例如,报表和出错信息等。 如下图所示:

外部输出

3)外部查询(External Inquiry:EQ)

外部查询是一个输入引出一个即时的简单输出,没有处理过程。 如下图所示:

外部查询

4)外部接口文件(External Interface Files :EIF’s)

用户可以识别的一组逻辑相关数据,这组数据只能被引用。用这些接口把信息传送给另一个系统如下图所示:

内部逻辑文件

5)内部逻辑文件(Internal Logical Files:ILF’S)

用户可以识别的一组逻辑相关的数据,而且完全存在于应用的边界之内,并且通过外部输入维护,是逻辑主文件的数目如下图所示:

内部逻辑文件

(5)功能计数项的复杂度等级

下面给出功能计数项的复杂度等级,如下图所示:

功能计数项的复杂度等级

(6)UFC计算实例

下面,我们用一个例子来举例。

某外贸订单项目的需求评估为:

外部输入3 项;外部输出1 项;外部查询1 项;外部接口文件1 项;内部逻辑文件2 项。请计算出该项目的 UFC

他们的复杂程度如下表所示:

功能点
简单 一般 复杂
外部输入 2 * 3 1 * 4 0 * 6
外部输出 0 * 4 0 * 5 1 * 7
外部查询 0 * 3 1 * 4 0 * 6
外部接口文件 0 * 5 1 * 7 0 * 10
内部逻辑文件 1 * 7 1 * 10 0 * 15
总计 13 25 7
UFC 45

(7)TCF-技术复杂度因子

TCF = 0.65 + 0.01(sum(Fi)),其中 Fi 为技术复杂度因子,其范围是 0-5TCF 的取值范围是 0.65-1.35

Fi 技术复杂度因子有 14 项,如下表所示:

技术复杂度因子
F1 可靠的备份和恢复 F2 数据通信
F3 分布式函数 F4 性能
F5 大量使用的配置 F6 联机数据输入
F7 操作简单性 F8 在线升级
F9 复杂界面 F10 复杂数据处理
F11 重复使用性 F12 安装简易型
F13 多重站点 F14 易于修改

技术复杂度因子的取值范围,如下表所示:

调整系数 描述
0 不存在或者没有影响
1 不显著的影响
2 相当的影响
3 平均的影响
4 显著的影响
5 强大的影响

(8)TCF计算实例

同样,我们用外贸订单项目的例子来计算 TCF 。假设 14 个复杂度因子的影响值都是平均,计算出该项目的功能点。

① U F C = 45

② TCF = 0.65+0.01(14*3)=1.07

③ FP= UFC*TCF = 45*1.07=48

④ 如果PE = 15工时/功能点,那么:Effort = 48*15= 720工时

(9)功能点与代码行的转换

语言 代码行/FP
Assembly 320
C 150
COBOL 105
FORTRAN 105
PASCAL 91
ADA 71
PL/1 65
PROLOG/LISP 64
SMALLTALK 21
SPREADSHEET 6

3、用例点估算法(重点)

(1)图例

用例模型如下图所示:

用例模型图示

(2)基本步骤

用例点估算方法的基本步骤为:

  • 计算未调整的角色的权值 UAW ;
  • 计算未调整的用例的权值 UUCW ;
  • 计算未调整的用例点 UUCP ;
  • 计算技术环境因子 TCFECF ;
  • 计算调整的用例点 UCP ;
  • 计算工作量 ( man-hours ) 。

接下来将依据这几个内容进行展开介绍。

(3)计算未调整的角色的权值UAW

公式: UAW=∑C=c aWeight(c) × aCardinality(c)

下面给出 Actor 权值定义表,如下表所示:

序号 复杂度级别 复杂度标准 权值
1 simple 角色通过API与系统交互 1
2 average 角色通过协议与系统交互 2
3 complex 用户通过GUI与系统交互 3

(4)计算未调整的用例的权值UUCW

公式: Uucw=∑C=c uWeight(c) × uCardinality(c)

下面给出 Use Case 权值定义表,如下表所示:

序号 复杂度级别 事务/场景个数 权值
1 simple 1-3 5
2 average 4-7 10
3 complex >7 15

(5)计算未调整的用例点UUCP

公式: UUCP = UAW + UUCW 。例如:

表1: Actor 权值

序号 复杂度级别 权值 参与角色数 UAWi
1 simple 1 2 2
2 average 2 4 8
3 complex 3 5 15

表2:Use Case 权值

序号 复杂度级别 权值 用例数 UUCWi
1 simple 5 5 25
2 average 10 2 20
3 complex 15 3 45

(6)计算技术因子TCF

公式: KaTeX parse error: Expected group after '_' at position 19: …=0.6+(0.01×\sum_̲\limits{i=1}^{1…_ Weighti × Valuei

假设现有某项目的复杂度因子如下图表所示:

序号 技术因子 说明 权值
1 TCF1 分布式系统 2.0
2 TCF2 性能要求 1.0
3 TCF3 最终用户使用效率 1.0
4 TCF4 内部处理复杂度 1.0
5 TCF5 复用程度 1.0
6 TCF6 易于安装 0.5
7 TCF7 系统易于使用 0.5
8 TCF8 可移植性 2.0
9 TCF9 系统易于修改 1.0
10 TCF10 并发性 1.0
11 TCF11 安全功能特性 1.0
12 TCF12 为第三方系统提供直接系统直接系统访问 1.0
13 TCF13 特殊的用户培训设施 1.0

具体的 TCF 值为:

TCF = 0.6+0.01×(2.0×3+1.0×5+1.0×3+1.0×5+1.0×0+0.5×3+0.5×5+2.0×3+1.0×5+1.0×3+1.0×5+1.0×0+1.0×0)=1.02

其中,调整系数为给定数值

(7)计算环境因子ECF

公式: KaTeX parse error: Expected group after '_' at position 20: …1.4+(-0.03×\sum_̲\limits{i=1}^{8…_ Weighti × Valuei) 。

假设现有某项目的环境因子如下表所示:

序号 环境因子 说明 权值
1 ECF1 UML 精通程度 1.5
2 ECF2 系统应用经验 0.5
3 ECF3 面向对象经验 1.0
4 ECF4 系统分析员能力 0.5
5 ECF5 团队士气 1.0
6 ECF6 需求稳定度 2.0
7 ECF7 兼职人员比例高低 1.0
8 ECF8 编程语言难易程度 1.0

假设调整系数已给定,那么具体的 ECF 值为:

ECF = 1.4+(-0.03×(1.5×3+0.5×3+1.0×3+0.5×5+1.0×3+2.0×3+1.0×0+1.0×0))=0.785

(8)计算调整的用例点UCP

公式: UCP = UUCP × TCF × ECF 。

依据上面所给出的结果,那么最终 UCP = UUCP × TCF × ECF = 115×1.02×0.785 = 92 。

(9)计算工作量

公式: Effort = UCP × PE 。

依据上面的数据,假设 PE=20工时/用例点 。那么: Effort = UCP × PE = 92×20=1840工时=230人天

4、类比(自顶向下)估算法

(1)定义

对于类比估算法来说,估算人员根据以往完成类似项目所消耗的总成本(或工作量),来推算将要开发的软件总成本(或工作量),然后按比例将它分配到各个开发任务单元中。

是一种自上而下的估算形式。

(2)什么时候使用

  • 有类似的历史项目数据
  • 信息不足(例如市场招标)的时候;
  • 要求不是非常精确估算的时候。

(3)主观判断举例

假设现在要开发某个证券交易网站,它的需求与往常开发的网站项目类似,且其历史数据是10万的开发成本。因此,用类比估算法来进行估算,它也是10万的开发成本。

5、自下而上估算法

(1)定义

利用任务分解图(WBS),对各个具体的工具包进行详细的成本估算,然后将结果累加起来得出项目总成本。如下图所示:

自下而上估算法

大家可以看到,左下方是一些估算的内容自下而上的原则右上方估算的结果

(2)特点

  • 相对比较准确,它的准确度来源于每个任务的估算情况。
  • 花费时间。

6、参数模型估算法(重点)

(1)定义

通过参数模型来估算(规模)成本的方法。

(2)使用条件

使用该模型的条件如下:

  • 具有良好的项目数据为基础;
  • 存在成熟的项目估算模型。

(3)特点

  • 比较简单,而且也比较准确
  • 如果模型选择不当或者数据不准,也会导致偏差

(4)参数模型:规模(成本)模型

1)面向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
2)面向FP驱动的
  • Albrecht and Gaffney:E = -12.39 + 0.0545FP
  • Matson,Barnett:E = 585.7 + 15.12FP
3)整体公式

整体公式为: E = a + b ∗ S c

E:以人月表示的工作量

a,b,c:经验导出的系数

S:主要的输入参数(通常是 LOCFP 等)

7、专家估算法(重点)

(1)定义

由多位专家进行成本估算,一个专家可能会有偏见,最好由多位专家进行估算,取得多个估算值,最后得出综合的估算值。

(2)专家估算法—Delphi

  • 组织者确定专家,这些专家互相不见面;
  • 组织者发给每位专家一份软件规格说明;
  • 专家以无记名对该软件给出3个规模的估算值;
    • 最小 a i
    • 最可能的 m i
    • 最大 b i
  • 组织者计算每位专家的 E i = ( ai + 4 m i + b i ) / 6 ;
  • 如果各个专家的估算差异超出规定的范围(例如:15%),则需重复上述过程;
  • 最终可以获得一个多数专家共识的软件规模: E = ( E 1 + E 2 + … E n ) / n (N: 表示 N 个专家)。

五、成本预算

1、成本预算的定义

  • 成本预算是将项目的总成本按照项目的进度分摊到各个工作单元中去
  • 成本预算的目的是产生成本基线

2、项目成本预算

分配项目成本预算包括三种情况:

  • 给任务分配资源成本
  • 给任务分配固定资源成本
  • 给任务分配固定成本

下面依据这三种情况进行一一介绍。

(1)给任务分配资源成本

  • 与资源的基本费率紧密相连
  • 设置资源费率
    • 标准费率
    • 加班费率
    • 每次使用费率
    • 。。。。。。

(2)分配固定资源成本

  • 当一个项目的资源需要固定数量的资金时,可以向任务分配固定资源成本。
  • 例如:项目中的一个兼职人员的成本。

(3)分配固定成本

  • 有些任务是固定成本的类型的任务,也就是说,管理者知道某项任务的成本不变,不管任务的工期有多长,或不管任务使用了哪些资源。在这种情况下,管理者可以向任务直接分配成本。
  • 例如:某外包任务、培训任务。

六、结束语

在上面的文章中,我们讲解软件项目中成本估算的基本概念,以及7种成本估算的方法。同时,我们还简单了解了一下成本预算

到这里,关于软件项目中的成本计划讲到这里就结束啦!不知道是否对小伙伴们有帮助呢?

🛵专栏直通车

软件项目管理👉juejin.cn/column/7024…

相关文章
|
11天前
|
弹性计算 人工智能 架构师
阿里云携手Altair共拓云上工业仿真新机遇
2024年9月12日,「2024 Altair 技术大会杭州站」成功召开,阿里云弹性计算产品运营与生态负责人何川,与Altair中国技术总监赵阳在会上联合发布了最新的“云上CAE一体机”。
阿里云携手Altair共拓云上工业仿真新机遇
|
8天前
|
机器学习/深度学习 算法 大数据
【BetterBench博士】2024 “华为杯”第二十一届中国研究生数学建模竞赛 选题分析
2024“华为杯”数学建模竞赛,对ABCDEF每个题进行详细的分析,涵盖风电场功率优化、WLAN网络吞吐量、磁性元件损耗建模、地理环境问题、高速公路应急车道启用和X射线脉冲星建模等多领域问题,解析了问题类型、专业和技能的需要。
2520 17
【BetterBench博士】2024 “华为杯”第二十一届中国研究生数学建模竞赛 选题分析
|
7天前
|
机器学习/深度学习 算法 数据可视化
【BetterBench博士】2024年中国研究生数学建模竞赛 C题:数据驱动下磁性元件的磁芯损耗建模 问题分析、数学模型、python 代码
2024年中国研究生数学建模竞赛C题聚焦磁性元件磁芯损耗建模。题目背景介绍了电能变换技术的发展与应用,强调磁性元件在功率变换器中的重要性。磁芯损耗受多种因素影响,现有模型难以精确预测。题目要求通过数据分析建立高精度磁芯损耗模型。具体任务包括励磁波形分类、修正斯坦麦茨方程、分析影响因素、构建预测模型及优化设计条件。涉及数据预处理、特征提取、机器学习及优化算法等技术。适合电气、材料、计算机等多个专业学生参与。
1522 14
【BetterBench博士】2024年中国研究生数学建模竞赛 C题:数据驱动下磁性元件的磁芯损耗建模 问题分析、数学模型、python 代码
|
3天前
|
存储 关系型数据库 分布式数据库
GraphRAG:基于PolarDB+通义千问+LangChain的知识图谱+大模型最佳实践
本文介绍了如何使用PolarDB、通义千问和LangChain搭建GraphRAG系统,结合知识图谱和向量检索提升问答质量。通过实例展示了单独使用向量检索和图检索的局限性,并通过图+向量联合搜索增强了问答准确性。PolarDB支持AGE图引擎和pgvector插件,实现图数据和向量数据的统一存储与检索,提升了RAG系统的性能和效果。
|
9天前
|
编解码 JSON 自然语言处理
通义千问重磅开源Qwen2.5,性能超越Llama
击败Meta,阿里Qwen2.5再登全球开源大模型王座
571 14
|
1月前
|
运维 Cloud Native Devops
一线实战:运维人少,我们从 0 到 1 实践 DevOps 和云原生
上海经证科技有限公司为有效推进软件项目管理和开发工作,选择了阿里云云效作为 DevOps 解决方案。通过云效,实现了从 0 开始,到现在近百个微服务、数百条流水线与应用交付的全面覆盖,有效支撑了敏捷开发流程。
19282 30
|
9天前
|
人工智能 自动驾驶 机器人
吴泳铭:AI最大的想象力不在手机屏幕,而是改变物理世界
过去22个月,AI发展速度超过任何历史时期,但我们依然还处于AGI变革的早期。生成式AI最大的想象力,绝不是在手机屏幕上做一两个新的超级app,而是接管数字世界,改变物理世界。
479 49
吴泳铭:AI最大的想象力不在手机屏幕,而是改变物理世界
|
1月前
|
人工智能 自然语言处理 搜索推荐
阿里云Elasticsearch AI搜索实践
本文介绍了阿里云 Elasticsearch 在AI 搜索方面的技术实践与探索。
18839 20
|
1月前
|
Rust Apache 对象存储
Apache Paimon V0.9最新进展
Apache Paimon V0.9 版本即将发布,此版本带来了多项新特性并解决了关键挑战。Paimon自2022年从Flink社区诞生以来迅速成长,已成为Apache顶级项目,并广泛应用于阿里集团内外的多家企业。
17528 13
Apache Paimon V0.9最新进展
|
2天前
|
云安全 存储 运维
叮咚!您有一份六大必做安全操作清单,请查收
云安全态势管理(CSPM)开启免费试用
364 4
叮咚!您有一份六大必做安全操作清单,请查收