类比估算的优缺点

不能使用于早期规模不确定的情况。 一般在已经有经验的狭窄领域。 难于适应新项目中约束条件、技术、人 员等发生重大变化的情况。
5.8 Albrecht功能点分析

功能点发进行估算的时候具体过程是： 1.对估算功能单元的类型进行识别 2.计算每种类型的复杂度． 3.计算总体的调整前的功能点数 4.根据调整因子对功能点数进行调整

5.4 软件估计基础 需要历史数据 工作的度量：SLOC/KLOC 复杂性：取决于估计人员的主观判 断

5.5 软件工作量估计技术
算法模型 专家判断 类比 帕金森法 嬴的价格 自顶向下 自底向上



5.5.1 由底向上估计
估计人员将项目分解成构件任务，然后估 计执行每个任务需要多少工作量。 由底向上法最适合于后期的更详细项目策 划阶段。 如果一个项目完全是新颖的或者没有可用 的历史数据，那么建议估计人员最好使用 由底向上方法。
5.12.1 基本COCOMO模型
E = ab(KLOC)exp(bb) D = cb(E)exp(db) 式中E为开发所需的人月，D为所需的开发 时间（月），KLOC为估计提交的代码行。 ab、bb 、 cb 、 db是指不同软件开发方式 的值。具体见下表：
5.12.1 基本COCOMO模型
生产率 = （KLOC）/E（代码行/人月） 人员数 = E/D
对付误差的方法

避免低劣估算 表达方式技巧

加减限定表示 范围表示 风险量化 分情况阐述

处理低劣估算带来的结果

功能点计算公式
FP = UFC *TCF 其中， UFC表示未调整的功能点计数； TCF表示技术复杂度因子。
5.8 Albrecht功能点分析
Albrecht复杂度因子（主观）
5.8 Albrecht功能点分析
技术复杂度因子
TCF=0.65+0.01（sum（Fi）） TCF范围：0.65—1.35



5.5.2 自顶向下法和参数模型
自顶向下法通常和参数模型相关。参数模型 公式如下：工作量 = 系统规模×生产率 预测软件开发工作量的模型有两个关键构件： 第一个是评估要承担的软件开发任务的规模 的方法；第二个是评估做每项任务的效率。


5.6 专家评判
专家评判往往是使用已标识的来自过去类



综合结果后，再次填写表格，比较估算 偏差，找出原因。 重复多次，最终获得一个多数认可的软 件规模。
5.7 类比估计


即基于案例的推理。估计人员从已经完成的项 目中找出与新项目有类似特征的项目，然后将 匹配的源案例已经记录的工作量作为目标案例 的估计基础。然后对新项目进行估计。 项目间的接近程度计算方法：

5.10 对象点
5.11 面向过程代码的方法
设想在最终系统中程序的数据和类型 估计每个已标识程序的SLOC 估计工作内容、考虑复杂度和技术难度 计算工作量（工作天数）

5.12 COCOMO模型
COCOMO：Constructive Cost Mode


分为基本COCOMO模型，和中级 COCOMO模型两种，前者是一个静态单 变量模型，对整个软件系统进行估算；后 者是一个静态多变量模型，将软件系统模 型分为系统和部件两个层次，系统是有部 件组成的。

软件的新颖应用 变更技术 缺乏同类项目的经验 估计的主观特性 角色因素
5.2 在何处进行估计
战略策划 可行性研究 系统规格说明 评价供应商建议书 项目策划


5.3 估计过高和估计过低的问题
帕金森定律：工作总是用完所有可以利用 的时间。 布鲁克斯定律：在一项延迟的工作上投入 更多的人，可能导致该项工作更加延迟。 估计实际上不是预测，而是一个管理目标。
例子：假设技术复杂度为平均水平
简单
外部输入 6
一般
2
复杂
3
外部输出
外部查询
7
0
7
2
0
4
外部文件
内部文件
5
9
2
0
32Biblioteka 1. 计算UFC简单
外部输入 6*3
一般
2*4
复杂
3*6
外部输出
外部查询
7*4
0*3
7*5
2*4
0*7
4*6
外部文件
内部文件
5*5
9*7
2*7
0*10
3*10
2*15
UFC=301
134
功能单元的类型

外部输入类型：通过界面等的输入，插入更新等 操作都是典型外部输入 外部输出类型：仅仅输出，入导出，报表，打印 等输出 内部逻辑文件类型：可以理解为业务对象，可能 对应多个数据表 外部接口文件类型：其它应用提供的接口数据 外部查询类型：先要输入数据，在根据输入数据 计算输出，如查询
似项目的非正式的类比法和由底向上估计 法相结合的方法。
Deiphi方法


组织者发给每位专家一份规格说明和记录表格， 请专家估算。 每位专家提出3个规模的估计值。

最小值ai 最可能值mi 最大值bi
组织者整理，计算每位专家的平均值 Ei = （ ai +4 mi + bi ）/6 计算期望值：E = (E1+……+En)/n
方式 有机 半有机 嵌入
ab
2.4 3.0 3.6
bb
1.05 1.12 1.2
cb
2.5 2.5 2.5
db
0.38 0.35 0.32



对于工作量E的公式, 当项目复杂性从有机向嵌入方式 转变时, 参数ab、bb 的取值逐步增加, 这反映了人力 的增长, 说明项目越复杂就需要越多的开发工作量。 而开发工期D的公式则不存在这种相应递增的关系, 即 随着项目复杂性的增加, 参数cb、db 并不相应增大, 这是由于开发部门对于复杂的大项目往往投入较强的 技术力量, 因此实际工期并不一定延长 这里需要指出的是上述参数取值仅仅是在63 个开发项 目的基础上用曲线拟合方法得到的, 因而只能作为一 种大致的测算公式。
165
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Ⅱ功能点
对于每个事务，为调整的功能点的计算方 法： Wi × (输入数据元素类型数) + We × (引用的实体类型数) + Wo × (输出数据元素类型数)
5.13 代码行的成本估算方法

求期望值Le和偏差Ld
a 4m b Le 6
ba Ld i 1 6
n 2
式中n表示软件功能数量
5.13 代码行的成本估算方法 根据经验数据，确定各子功能的代码 成本行 计算各子功能的成本和工作量 计算开发时间 对结果进行分析比较



5.13 软件生产率
软件生产率是指每个人一个月所能生产的 有效源代码行数。 对软件生产率影响的因素很多，要得到准 确结果并不容易。其影响因素为： 人的因素、问题因素、过程因素、生 产因素、资源因素。


5.13 代码行的成本估算方法
确定功能


首先将功能反复分解，直到可以对为实现该功 能所要求的源代码行数做出可靠的估算为止。 然后可以给出极好、正常和较差三种情况下的 源代码估算行数的期望值，分别用a、m、b 表示。

估算的误差度
类型
量级估计：合 同前 预算估计：合 同期 确定性估计： WBS之后
准确度
-25%---+75% -10%---+25% -5%---+10%
说明
概念和启动阶 段 初步计划 详细计划
估算不准的主要原因

基础数据不足 对需求理解的程度 软件项目的不确定 缺乏经验的估计人员 签约前后不连贯和低劣的推测技术
第5章 软件工作量估计
本章目的
避免不现实估计的危险 了解可以使用的估计方法的适用范围 使用由底向上的方法估计项目 计算系统的功能点和对象点 估计使用过程编程语言实现软件所需要的 工作量 了解开发工作量模型COCOMO方法



5.1 引言
成功项目的一个定义是系统能够按时和在 预算内交付，并能满足要求的质量。 估计过程的困难：
欧几里得距离：[(目标参数1-源参 数1)2+ … +(目标参数n-源参数n)2]1/2
类比估算要解决的问题：


如何描述实例特征。 通过选取合适的相似度、相异度的表达 式，评价相似程度。 如何用相似的项目数据得到最终估算值。
例子：

假定比较的案例基于两个参数。即构建 系统的输入数和输出数。已知新项目有7 个输入和15个输出。过去有一个项目A有 8个输入和17个输出。项目B有5个输入和 10个输出。求欧几里得距离，判断项目A 和B那个更接近新项目。
5.12.2 中级COCOMO模型
基本模型考虑了软件开发方式和软件规模 这两个重要因素, 为了提高测算精度，采 用中级COMOCO模型。 先产生一个与基本COCOMO模型一样形 式的估算公式，然后对15个“成本驱动属 性”进行打分，定出“乘法因子”，对公 式进行休整。 产品属性 计算机属性 人员属性 项目属性