软件项目管理--软件工作量估算

最新推荐文章于 2024-06-19 07:00:00 发布

Dashesand

最新推荐文章于 2024-06-19 07:00:00 发布

阅读量7.1k

点赞数 8

文章标签：软件工程项目管理

本文链接：https://blog.csdn.net/weixin_42907150/article/details/127613147

版权

软件项目管理软件工作量估计

本章要点

估算过程概念
估算方法
成本预算
案例分析
课程实践

关于估算

估算不是很正确，有误差
项目经验数据非常重要
不要太迷信某些数学模型

软件项目规模

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

软件规模单位

loc源代码长度的测量
fp 用系统的功能数量来测量

工作量

人月
人天
人年

软件项目成本

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

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

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

成本估算结果

直接成本：与具体项目相关的成本，例如参与项目的人员成本
间接成本：可以分摊到各个具体项目中的成本
- 培训
- 房租水电
- 员工福利
- 市场费用
- 管理费
- 其他等

下面关于估算的说法，错误的是（）

A、估算是有误差的

B、估算时不要太迷信数学模型

C、经验对于估算来说不重要

D、历史数据对于估算来说非常重要

（）是成本的主要因素，是成本估算的基础。

A、计划

B、规模

C、风险

D、利润

估算方法

软件工作量估计–两种基本的成本估算形式

自顶向下：首先定义整个项目的工作量，然后分解到各个部分
自底向上：各个部分的工作量先估算出来，然后进行合成

自顶向下方法

是对整个工程项目的总开发时间和总工作量作出估算，然后将他们按阶段，步骤和任务进行分配

自底向上方法

该方法首先将项目分成部件任务，然后估算每个任务所需的工作量
在大型的项目中，分解任务的过程是一个叠代的过程，直到最下面的任务不可分解，产生wbs
该方法适合与项目规划的后期，如果应用在前期，那么必须对最终的系统走出一些假设，加入对软件模块的数量和大小进行假设
如果项目是全新的或者没有历史数据，建议用该方法

自顶向下方法和参数模型法

自定向下的方法和参数模型相关
一般采用对比方法确定总的工作量
对比是建立在一些列参数的基础上的，通过这些参数可以计算出新系统的工作量
系统规模*生产率
- 例如系统规模可以用kloc来计算，生产率以40/kloc
- 预测软件开发工作链的模型由两部分，第一部分为估算软件大小，第二部分为估算工作效率

学生要求每学期写一篇有关IT的报告，如果你想建立一个估算学生完成这样一份报告的模型，你用什么来衡量报告的大小，什么因素会影响学生完成报告的难度？

最明显的工作量驱动因子是:

字数

难度因子可能包括:

材料的可获得性

学生对主题的熟悉程度

需要的宽度/深度

技术难度

专家判断

具有应用领域或者开发环境只是的人员对任务的评估
该方法特别是在对原有系统进行替换时有用，评估者对影响的代码的比例进行分析，从而得到工作量评估

类比估计

类比方法又被称为基于案例的推理

评估者寻找已经完成的项目，这些项目与需要开发的新项目在许多特征上必须是类似的

如何选择与带预测的项目相近的项目？

欧几里得数学公式
distance

假定要匹配的案例基于两个参数,构造系统的输入和输出参数。新的系统有7个输入，15个输出，过去有一个项目A有8个输入，17个输出，这两个项目的欧几里的距离是多少？

估算基本方法

代码行估算法
功能点估算法
用例点估算法
类比（自顶向下）估算法
自上而下估算法
参数估算法
专家估算法

基于分解技术的估算

基于问题的估算

利用loc/pm，fp/pm等生产率度量，我们能得到功能的成本和工作量
对于loc估计，分解越详细越好
对于fp估计，需要五个信息域
估算的三点或期望值估算
为各个功能或信息域的计数值分别估算出一个乐观值、可能值和悲观值

一个例子

loc估算方法，机械设计计算机辅助设计开发软件包

这类系统的组织平均生产率是620loc/pm

如果一个劳动力价格=8000/月，则每行代码的成本约为13美元 8000/620=13

13*33200=431000

33200/620=54

根据loc估算及历史生产率数据，该项目总成本的估算值是431000美元，工作量的估算值是54人月

lDo a functional decompostion of the robot software.Estimate the size of robot system as 6450 LOC .Assuming that your organization produces 450 LOC/pm with a burdened labor rate of $7000 per person-month,estimate the effort and cost required to build the software using the LOC-based estimation technique described in this chapter.

l对机器人软件进行功能分解。估计机器人系统的规模为6450个LOC。假设您的组织生产450个LOC/pm，人工负担为每人每月7000美元，使用本章所述的基于LOC的估计技术估计构建软件所需的工作量和成本。

7000/450=15.5

100333

14.333

适用代码行估算方法的项目特点

从软件程序量的角度定义项目规模

与具体的编程语言有关
分解足够详细
有一定经验数据（类比和经验方法）

代码行技术的主要优点

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

代码行估算方法的缺点

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

功能点估算法

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

功能点共识

fp=ufc*tfc

ufc：未调整功能点计数

tcf：技术复杂度因子

ufc-未调整功能点计数

功能计数项（从逻辑处理的角度）

外部输入
- 给软件提供面向应用的数据的项（如屏幕、表单、对话框、控件、文件等）在这个过程中，数据穿越外部边界进入到系统内部
外部输出
- 向用户提供（经过处理的）面向应用的信息，例如，报表和出错信息等
外部查询
- 外部查询是一个输入引出一个及时的简单输出，没有处理过程
外部接口文件
- 外部接口文件是用户可以识别的一组逻辑相关数据，这组数据只能被引用。用这些接口把信息传送给另一个系统
内部逻辑文件
- 用户可以识别的一组逻辑相关的数据，而且完全存在与应用的边界之内，并且通过外部输入维护，是逻辑主文件的数目

ufc-微调整功能点计数

功能计数项的复杂度等级

		复杂度权重因素
项	简单	一般	复杂
外部输入	3	4	6
外部输出	4	5	7
外部查询	3	4	6
外部接口文件	5	7	10
内部逻辑文件	7	10	15

还有哪些因素会影响实现功能点的难度？

调整因子	值（0-5）
1.需要备份和恢复	4
2.需专门数据通信	2
3.存在分布式处理吗	0
4.性能是关键的吗	4
5.运行在现有的紧张操作环境吗	3
6.系统需要在线数据项吗	4
7.需要多屏幕输入切换吗	5
8.主文件联机更新吗	3
9.输入输出文件或查询是复杂的吗	5
10.内部处理是否复杂	5
11.设计的代码可复用吗	4
12.转换与安装包含在设计中吗	3
13.为多个安装而设计的吗	5
14.具有易于变更，易于用户设计的应用设计	5
复杂度校正因子	1.17

复杂度矫正因子

最后得出的fp的估算值为

fp=总计**[（0.65+0.01*sum（fi)]

在学院工资系统项目中需要开发一个程序，该程序将从会计系统中提取每年的工资额，并从两个文件中分别提取课程情况和每个老师教的每一门课的时间，该程序将计算每一门课的老师的成本并将结果存成一个文件，该文件可以输出给会计系统，同时该程序也将产生一个报表，以显示对于每一门课，每个老师教学的时间和这些工时的成本。

假定报表是具有高度复杂性的，其它具有一般复杂性

外部输入：无
外部输出：报告，1
内部逻辑文件：财务输入文件，1
外部接口文件：工资文件，人员文件，课程文件，财务输入文件，4
外部查询：无

考虑加权

外部输入：无外部输出：1*7
内部逻辑文件1*10
外部接口文件4*7=28
外部查询：无

总45

fp估算方法举例

根据那个面的外贸订单项目的需求评估

外部输入：3项外部输出：1项外部查询：1项

外部接口文件：1项内部逻辑文件：2项

TCF-技术复杂度因子

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

功能点方法：复杂性判定

如何判定功能的复杂性

国家功能点用户小组

内部逻辑文件、外部接口文件
外部输入文件
外部输出文件
如何确定记录个数和数据个数
- 如某系统内部逻辑文件，订单文件，包含订单信息（包含订单号，供应商名称，订单日期）和订单项（包括商品号，价格和数目），则记录个数为2，数据个数为6，在表中可以确定该功能点复杂性为低

技术复杂度因子的取值范围

外贸订单项目

fp=ufc*tcf

ufc=45

tcf=0.65+0.01（14*3）=1.07

fp=45*1.07=48

如果pe=15工时/功能点

则effort=48*15=720工时

功能点与代码行的转换

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

Compute the function point value for a project with the following information domain characteristics:

number of user inputs:32

number of user outputs:60

number of user inquiries:24

number of files:8

number of external interfaces:2

Assuming the project is simple and all complexity adjustment values are average.

基于过程的估算

估算项目最常用的方法是基于过程的估算
将过程分解为一组相对较小的活动、行动和任务，并估计完成每个活动、行动和任务所需的工作量

基于过程的估算从描述项目范围获得软件功能开始
必须为每个功能执行一系列框架活动
功能和相关框架活动可以用类似下表的一部分表示

在表中，功能和过程活动被融合。我们可以估计完成每个软件功能的每个软件过程活动所需的工作量，例如人月

这些数据构成了表格中心矩阵

然后平均人工费率（成本/单位工作量）*每个过程活动的估算工作量，并得出成本

1.请说出基于过程的估算步骤

2.请说出下图中行列内容表示什么意思

3.从下图中哪个过程需要的工作量大，为什么

如果一个平均劳动力价格是每月8000美元，则项目总成本的估算值是368,000美元，工作量的估算值是46人月

分析设计，编码，测试各自应该占总工作量的比例大概是多少（百分比）

40-20-40原则

用例点估算

1.计算未调整的角色的权值UAW;

2.计算未调整的用例的权值UUCW ;

3.计算未调整的用例点UUCP;

4.计算技术和环境因子TEF;

5.计算调整的用例点UCP ;

6.计算工作量( man－hours) 。

计算为调整的角色的权值

UAW=

计算未调整的用例的权值UUCW

UUCW=

计算为调整的用例点UUCP

UUCP=UAW+UUCW

计算技术因子TCF

前面除了客观技术方面的因素能影响到项目工作量

主观方面，人的哪些因素能影响到项目工作量？

计算环境因子ECF

计算调整的用例点UCP

计算工作量

如果沒有歷史数据可供参考，行业专家推荐使用15-30之间的一个数字，典型的，你可使用20小时/ucp
与专家估算法相比，用例点估算可能偏高，公式中的变量需要进行调整，特别是刚开始这样估算时
场景中的步数，很多的步数将复杂性偏高，用例点增大，较少的步数使复杂性偏低
包含和扩充用例增大了复杂性，将这些记为单独的用例
用例中的角色数也影响估算。如果可能，将角色归纳为更高层次的角色，浙江减少复杂性而不影响用例
技术和环境因素需要根据不断获得实际数据来做调整，越多项目使用用例点数来估算，估算将越准确

生产力因素智能从历史资产中获得。在没有得到符合公司生产的生产力基准数据前。将生产力划分为三个等级。高级工程师15人时/ucp；中级工程师20人时/ucp；初级工程师30人时/ucp

类比（自顶向下）估算法

估算人员根据以往的完成类似项目所消耗的总成本，来推算将要开发的软件的总成本。然后按比例将他分配到各个开发任务单园中

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

自顶向下发是对整个工程项目的总开发时间和，然后将他们按阶段，步骤任务进行分配

类比估算–使用情况

有类似的历史项目数据
信息不足的时候（例如市场招标）
要求不是很精确估算的时候

类比估算–主观判断举例

证券交易网站

需求类似
历史数据：10万
类比估算：10万

自下而上估算

利用任务分解图，对各个具体工作包进行详细的成本估算，然后将结果累加起来得出项目总成本

相对比较准群，他的准确度来源于每个任务的估算情况
花费时间

自下而上估算举例

软件项目成本计划

参数估算法

通过项目数据，进行回归分析，得出回归模型
通过参数模型估算（规模）成本的方法
具有良好的项目数据为基础
存在成熟的项目估算模型

特点

比较简单，而且也比较准确

如果模型选择不当或者数据不准，也会导致偏差

参数模型（规模、成本模型）

面向loc驱动的

建议掌握

Walston-Felix模型

Cocomo模型

乘法因子的成本驱动属性

产品属性
平台属性
人员属性
过程属性

n在企业中，绝大多数系统技术上，产品，计算机和项目等属性都是类似的。只有人员的属性有所差异。该企业制定了下表：

分析员非常优秀，编程人员也很优秀但是对该项目面向的领域不熟悉并准备用新的编程语言。他们对操作系统很熟悉。请计算dem。如果名义工作量是4人月，则估算的工作量是多少？

高级COCOMO

讲项目分解为一系列的子系统或者子模型
更加精确的调整一个模型的属性

一个明显的特点是该模型适应了项目在执行过程中变得越来越确定的状态，因而是一种渐进性评估

COCOMO II

应用组装模型–规划阶段
早起设计模型–设计阶段
后体系结构模型–开发阶段

在应用构成阶段，采用对象点计算的方法
在早期设计阶段，采用功能点计算的方法，功能点可以转换为KLOC
pm=AxSIZEXEM1XEM2X…XEMN
pm为人月工作量，A是一个常数，size以kloc为单位，sf是指数比例因子
sf=1.01+0.01x指数驱动因子的和

计算规模因素的质量(0-5）

先前经验（Precedentedness): 是否有先前的经验

开发的灵活性（Development Flexibility): 是否需求能够以多种方式来满足；

体系结构/风险解决(Architecture/Risk Resolution)：是否方案已经被确定和解决的程度

团队的凝聚性（Team cohesion)

过程的成熟性（Process Maturity)

对于某一个软件企业，一个新的项目的新颖性一般，因而在先前经验方面给3分，开发灵活性方面很低，因而给以0分，但是需求可能会变化得比较厉害，因而风险解决指数给4分，团队很融洽，给1分，但是过程不标准，因而过程成熟性给4分，请计算规模因素sf：

计算工作量乘法算子em

类似于dem的计算

在不同的阶段有不同的em

如果每一项对于项目而言无特别影响，则取1

专家估算法

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

组织者确定专家，这些专家互相不见面
组织者发送给每位专家一份软件规格说明
专家以无记名对该软件给出3个规模的估算值
- 最小ai
- 最可能的mi
- 最大bi
组织者计算每位专家的ei=（ai+4mi+bi）/6
如果各个专家的估算差异超出规定的范围，则需重复上述过程
最终可以获得一个多数专家共识的软件规模取平均

实用软件估算步骤

是一种自下而上和参数法的结合模型，步骤如下

对任务进行分解：1,2,…,i,…n
直接成本=E1+E2+…EI+…+EN
间接成本估算
项目总估算成本=直接成本+间接成本

直接估算成本Ei
先估算规模Qi，然后估算成本Ei=Qi*人力成本参数

直接成本估算

直接成本组成

开发成本
管理成本
质量成本

人力成本参数=5万/人月 30人月包括开发、管理、质量规模的项目的直接成本是150万

项目总估算成本

估算成本=直接成本+间接成本
估算成本=直接成本+直接成本*间接成本系数
估算成本=直接成本（1+间接成本系数）
估算成本=规模*人力成本参数（1+间接成本系数）
成本系数=人力成本参数*（1+间接成本系数）

简易算法

估算成本=规模*成本系数
例如：成本系数=8万/人月

成本预算

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

成本预算的目的是产生成本基线

分配项目成本预算包括3中情况

给任务分配资源成本
1. 与资源的基本费率紧密相连
2. 设置资源费率
  1. 标准费率
  2. 加班费率
  3. 每次使用费率
给任务分配固定资源成本
1. 当一个项目的资源需要固定数量的资金时，可以项任务分配固定资源成本。例如，项目中的一个兼职人员成本
给任务分配固定成本
1. 有些任务是固定成本的类型的任务，也就是说，管理者知道某项任务的成本不变，不管任务的工期有多长，或不管人物使用了哪些资源，在做这种情况下，管理者向任务直接分配成本
  1. 某外包任务、培训任务