第十八章 规模估算中的特殊问题

一旦从直接估算工作量和进度转为基于历史数据来对其进行计算，项目的规模就成为了最难估算的量。在迭代式项目中使用规模估算有助于确定在一次迭代中可以交付多少特性，但人们通常关注的还是可直接估算特性的方法。而在顺序式项目的后期，估算则更关注由负责特定工作的人自底向上地进行工作量估算。因此，规模估算主要适用于顺序式项目的早期和中期阶段。规模估算的目的是在不确定性堆较宽的时候提供长期的可预测性。

常见的代码行和功能点度量的规模度量方法都有各自的优缺点，各开发组织使用的定制度量方法也同样如此。如果使用多种规模度量方法进行估算，然后研究它们的收敛或分散情况，可以获得最准确的结果。

本章将说明如何进行规模估算。

18.1 软件规模估算中的挑战

规模度量有多种方法，主要包括：

• 特性（feature）
• 用户故事（user story）
• 故事点（story point）
• 需求（requirement）
• 用例（use case）
• 功能点（function point）
• web页面数
• GUI组件（窗口、对话框、报表等等）
• 数据库表
• 接口定义
• 类
• 函数/子例程
• 代码行

代码行度量是在估算中最常用的规模度量方法

代码行在规模估算中的作用

对软件估算而言，使用代码行是好坏各班的做法。从积极方面来看，代码行带来的益处包括：

• 很容易使用工具来收集过去项目的代码行数据
• 很多开发组织中有大量以代码行形式存在的历史数据
• 在多种编程语言中，编写每行代码行所需的工作量大致上是相同的，或者是足够接近的
• 以代码行表示的度量结果可以进行跨项目的比较，以及根据历史项目的数据来估算未来项目
• 大部分商用估算工具最终都使用代码行作为工作量和进度估算的基础

从消极方面看，使用代码行度量进行规模估算也带来了一些困难：

• 由于软件的规模不经济现象，以及不同类型软件的编码速度差异很大，类似 "每人月完成代码行数" 的简单模型很容易出错
• 不能根据代码行来对个人的任务分配进行估算，因为不同程序员的生产率有很大差异；
• 如果项目实际需要的代码复杂度高于用于校准生产率假设的项目的代码复杂度，估算的准确度会降低；
• 使用代码行度量作为对需求工作、设计工作和编码之前的其他活动进行估算的基础似乎是违背人的直观感受的（因为这些工作并不能直接体现为代码，译者注）；
  难以直接进行代码行估算，必须通过代理进行估算；
• 必须小心地定义一个代码行到底包括哪些内容，以避免8.2节“要收集的数据”中的“与规模度量有关的问题”中描述的问题。

代码行、功能点和其他简单的规模度量方法中都会出现的根本问题在于，如果使用单维的度量方法来度量像软件规模这样涉及多方面的问题，就不可避免地会在某些情况下产生异常的结果

代码行是度量软件规模的糟糕方法，不过所有其他的规模度量方法都更糟

18.2 功能点估算

程序中的功能点数目是根据下列对象的数量和复杂度得到的：

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

18.3 简化的功能点方法

1）Dutch 方法

在这种方法中，只对内部逻辑文件和外部接口文件计数，而不是对所有输入、输出和查询进行计数

指示性功能点计数 = (35 * 内部逻辑文件)+ （15 * 外部接口文件）

2）GUI元素