软件工作量估计

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

人员数 = E/D
方式
ab
bb
cb
db
有机
2.4
1.05
2.5
0.38
半有机
3.0
1.12
2.5
0.35
嵌入
3.6
1.2
2.5
0.32
对于工作量E的公式, 当项目复杂性从有机向嵌入方式 转变时, 参数ab、bb 的取值逐步增加, 这反映了人力 的增长, 说明项目越复杂就需要越多的开发工作量。
而开发工期D的公式则不存在这种相应递增的关系, 即 随着项目复杂性的增加, 参数cb、db 并不相应增大, 这是由于开发部门对于复杂的大项目往往投入较强的 技术力量, 因此实际工期并不一定延长
估算的误差度
类型
准确度
说明
量级估计:合 -25%---+75% 概念和启动阶
同前

预算估计:合 -10%---+25% 同期
初步计划
确定性估计: -5%---+10% WBS之后
详细计划
估算不准的主要原因
基础数据不足 对需求理解的程度 软件项目的不确定 缺乏经验的估计人员 签约前后不连贯和低劣的推测技术
对付误差的方法
避免低劣估算 表达方式技巧
加减限定表示 范围表示 风险量化 分情况阐述
处理低劣估算带来的结果
预测软件开发工作量的模型有两个关键构件: 第一个是评估要承担的软件开发任务的规模 的方法;第二个是评估做每项任务的效率。
5.6 专家评判
专家评判往往是使用已标识的来自过去类 似项目的非正式的类比法和由底向上估计 法相结合的方法。
Deiphi方法
组织者发给每位专家一份规格说明和记录表格, 请专家估算。
COCOMO:Constructive Cost Mode
分为基本COCOMO模型,和中级 COCOMO模型两种,前者是一个静态单 变量模型,对整个软件系统进行估算;后 者是一个静态多变量模型,将软件系统模 型分为系统和部件两个层次,系统是有部 件组成的。
5.12.1 基本COCOMO模型
类比估算的优缺点
不能使用于早期规模不确定的情况。 一般在已经有经验的狭窄领域。 难于适应新项目中约束条件、技术、人
员等发生重大变化的情况。
5.8 Albrecht功能点分析
功能点发进行估算的时候具体过程是: 1.对估算功能单元的类型进行识别 2.计算每种类型的复杂度. 3.计算总体的调整前的功能点数 4.根据调整因子对功能点数进行调整
每位专家提出3个规模的估计值。
最小值ai 最可能值mi 最大值bi
组织者整理,计算每位专家的平均值 Ei = ( ai +4 mi + bi )/6 计算期望值:E = (E1+……+En)/n
综合结果后,再次填写表格,比较估算 偏差,找出原因。
重复多次,最终获得一个多数认可的软 件规模。
布鲁克斯定律:在一项延迟的工作上投入 更多的人,可能导致该项工作更加延迟。
估计实际上不是预测,而是一个管理目标。
5.4 软件估计基础
需要历史数据 工作的度量:SLOC/KLOC 复杂性:取决于估计人员的主观判

5.5 软件工作量估计技术
算法模型 专家判断 类比 帕金森法 嬴的价格 自顶向下 自底向上
Wi × (输入数据元素类型数) +
We × (引用的实体类型数)
+
Wo × (输出数据元素类型数)
5.10 对象点
5.11 面向过程代码的方法
设想在最终系统中程序的数据和类型 估计每个已标识程序的SLOC 估计工作内容、考虑复杂度和技术难度 计算工作量(工作天数)
5.12 COCOMO模型
估计过程的困难:
软件的新颖应用 变更技术 缺乏同类项目的经验 估计的主观特性 角色因素
5.2 在何处进行估计
战略策划 可行性研究 系统规格说明 评价供应商建议书 项目策划
5.3 估计过高和估计过低的问题
帕金森定律:工作总是用完所有可以利用 的时间。
复杂 3*6 0*7 4*6 3*10 2*15 102
2. 计算TCF
TCF = 0.65 + 0.01*(14*3) =1.07
3. 计算功能点FP
FP = UFC*TCF =301*1.07=322
5.9 MarkⅡ功能点
5.9 MarkⅡ功能点
对于每个事务,为调整的功能点的计算方 法:
第5章 软件工作量估计
本章目的
避免不现实估计的危险 了解可以使用的估计方法的适用范围 使用由底向上的方法估计项目 计算系统的功能点和对象点 估计使用过程编程语言实现软件所需要的
工作量 了解开发工作量模型COCOMO方法
5.1 引言
成功项目的一个定义是系统能够按时和在 预算内交付,并能满足要求的质量。
5.7 类比估计
即基于案例的推理。估计人员从已经完成的项 目中找出与新项目有类似特征的项目,然后将 匹配的源案例已经记录的工作量作为目标案例 的估计基础。然后对新项目进行估计。
项目间的接近程度计算方法:
欧几里得距离:[(目标参数1-源参 数1)2+ … +(目标参数n-源参数n)2]1/2
类比估算要解决的问题:
如何描述实例特征。 通过选取合适的相似度、相异度的表达
式,评价相似程度。 如何用相似的项目数据得到最终估算值。
例子:
假定比较的案例基于两个参数。即构建 系统的输入数和输出数。已知新项目有7 个输入和15个输出。过去有一个项目A有 8个输入和17个输出。项目B有5个输入和 10个输出。求欧几里得距离,判断项目A 和B那个更接近新项目。
5.13 代码行的成本估算方法
求期望值Le和偏差Ld
Le a 4m b 6
Ld n b a 2 i1 6
式中n表示软件功能数量
5.13 代码行的成本估算方法
根据经验数据,确定各子功能的代码 成本行
计算各子功能的成本和工作量 计算开发时间 对结果进行分析比较
5.5.1 由底向上估计
估计人员将项目分解成构件任务,然后估 计执行每个任务需要多少工作量。
由底向上法最适合于后期的更详细项目策 划阶段。
如果一个项目完全是新颖的或者没有可用 的历史数据,那么建议估计人员最好使用 由底向上方法。
5.5.2 自顶向下法和参数模型
自顶向下法通常和参数模型相关。参数模型 公式如下:工作量 = 系统规模×生产率
产品属性 计算机属性 人员属性 项目属性
5.13 软件生产率
软件生产率是指每个人一个月所能生产的 有效源代码行数。
对软件生产率影响的因素很多,要得到准 确结果并不容易。其影响因素为: 人的因素、问题因素、过程因素、生 产因素、资源因素。
5.13 代码行的成本估算方法
确定功能
首先将功能反复分解,直到可以对为实现该功 能所要求的源代码行数做出可靠的估算为止。 然后可以给出极好、正常和较差三种情况下的 源代码估算行数的期望值,分别用a、m、b 表示。
例子:假设技术复杂度为平均水平
外部输入 外部输出 外部查询 外部文件 内部文件
简单 6 7 0 5 9
一般 2 7 2 2 0
复杂 3 0 4 3 2
1. 计算UFC
简单
外部输入
6*3
外部输出
7*4
外部查询
0*3
外部文件
5*5
wenku.baidu.com
内部文件
9*7
UFC=301
134
一般 2*4 7*5 2*4 2*7 0*10 165
功能点计算公式
FP = UFC *TCF 其中, UFC表示未调整的功能点计数; TCF表示技术复杂度因子。
5.8 Albrecht功能点分析
Albrecht复杂度因子(主观)
5.8 Albrecht功能点分析
技术复杂度因子
TCF=0.65+0.01(sum(Fi)) TCF范围:0.65—1.35
功能单元的类型
外部输入类型:通过界面等的输入,插入更新等 操作都是典型外部输入
外部输出类型:仅仅输出,入导出,报表,打印 等输出
内部逻辑文件类型:可以理解为业务对象,可能 对应多个数据表
外部接口文件类型:其它应用提供的接口数据 外部查询类型:先要输入数据,在根据输入数据
计算输出,如查询
这里需要指出的是上述参数取值仅仅是在63 个开发项 目的基础上用曲线拟合方法得到的, 因而只能作为一 种大致的测算公式。
5.12.2 中级COCOMO模型
基本模型考虑了软件开发方式和软件规模 这两个重要因素, 为了提高测算精度,采 用中级COMOCO模型。
先产生一个与基本COCOMO模型一样形 式的估算公式,然后对15个“成本驱动属 性”进行打分,定出“乘法因子”,对公 式进行休整。
E = ab(KLOC)exp(bb) D = cb(E)exp(db) 式中E为开发所需的人月,D为所需的开发
时间(月),KLOC为估计提交的代码行。 ab、bb 、 cb 、 db是指不同软件开发方式 的值。具体见下表:
5.12.1 基本COCOMO模型
生产率 = (KLOC)/E(代码行/人月)
相关文档
最新文档