估算技术 - 快速指南

---

估算技术 - 概述

估计是寻找估计值或近似值的过程，即使输入数据可能不完整、不确定或不稳定，该值也可用于某种目的。

估算确定构建特定系统或产品需要多少资金、精力、资源和时间。估计基于 -

• 过去的数据/过去的经验
• 可用文档/知识
• 假设
• 已识别的风险

软件项目估算的四个基本步骤是 -

• 估计开发产品的大小。
• 以人月或人时为单位估计工作量。
• 估计日历月的时间表。
• 以商定的货币估算项目成本。

估计观察

• 估算不必是项目中的一次性任务。它可以发生在 -

  • 收购项目。
  • 规划项目。
  • 根据需要执行项目。

• 在估算过程开始之前必须了解项目范围。拥有历史项目数据将会很有帮助。

• 项目指标可以为生成定量估计提供历史视角和有价值的输入。

• 规划需要技术经理和软件团队做出初步承诺，因为它会带来责任和问责。

• 过去的经验可以提供很大帮助。

• 至少使用两种估计技术来得出估计值并协调结果值。请参阅下一节中的分解技术，了解协调估计的信息。

• 计划应该是迭代的，并允许随着时间的推移和了解更多细节而进行调整。

一般项目估算方法

广泛使用的项目估算方法是分解技术。分解技术采用分而治之的方法。通过将项目分解为主要功能或相关的软件工程活动，逐步进行规模、工作量和成本估算。

步骤 1 - 了解要构建的软件的范围。

步骤 2 - 生成软件大小的估计。

• 从范围声明开始。

• 将软件分解为每个可以单独估计的函数。

• 计算每个函数的大小。

• 通过将规模值应用于基准生产力指标来得出工作量和成本估算。

• 结合功能估计来生成整个项目的总体估计。

步骤 3 - 生成工作量和成本的估计。您可以通过将项目分解为相关的软件工程活动来估算工作量和成本。

• 确定完成项目所需执行的活动顺序。

• 将活动划分为可衡量的任务。

• 估计完成每项任务所需的工作量（以人小时/天为单位）。

• 结合活动任务的工作量估计来生成活动的估计。

• 从数据库中获取每项活动的成本单位（即成本/单位工作量）。

• 计算每项活动的总工作量和成本。

• 结合每项活动的工作量和成本估算，生成整个项目的总体工作量和成本估算。

步骤 4 - 协调估计：将步骤 3 的结果值与步骤 2 获得的值进行比较。如果两组估计值一致，则您的数字高度可靠。否则，如果出现广泛不同的估计，请进一步调查是否 -

• 项目的范围没有被充分理解或被误解。

• 功能和/或活动细分不准确。

• 用于估计技术的历史数据不适合应用，或已过时，或已被误用。

步骤 5 - 确定差异的原因，然后协调估计值。

估计准确度

准确性表明事物与现实的接近程度。每当您生成估计值时，每个人都想知道数字与实际情况的接近程度。考虑到生成时所拥有的数据，您将希望每个估计都尽可能准确。当然，您不希望以激发对数字的错误信心的方式来呈现估计值。

影响估计准确性的重要因素是 -

• 所有估计输入数据的准确性。

• 任何估计计算的准确性。

• 用于校准模型的历史数据或行业数据与您估计的项目的匹配程度。

• 您组织的软件开发过程的可预测性。

• 产品需求和支持软件工程工作的环境的稳定性。

• 实际项目是否经过精心策划、监控和控制，没有发生重大意外导致意外延误。

以下是一些实现可靠估计的指南 -

• 根据已完成的类似项目进行估算。
• 使用相对简单的分解技术来生成项目成本和工作量估算。
• 使用一种或多种经验估计模型来估计软件成本和工作量。

请参阅本章中的估算指南部分。

为了确保准确性，始终建议您至少使用两种技术进行估计并比较结果。

估算问题

通常，项目经理会通过估算进度来跳过估算规模。这可能是因为高层管理人员或营销团队设定的时间表。然而，无论出于什么原因，如果这样做，那么在以后的阶段将很难估计时间表以适应范围的变化。

在估计时，可以做出某些假设。重要的是要注意估计表中的所有这些假设，因为有些假设仍然没有在估计表中记录假设。

即使好的估计也有固有的假设、风险和不确定性，但它们常常被视为准确的。

表达估计的最佳方式是表示一系列可能的结果，例如，项目将需要 5 到 7 个月的时间，而不是说它将在特定日期完成或将在固定的时间内完成。几个月。注意不要承诺一个太窄的范围，因为这相当于承诺一个明确的日期。

• 您还可以将不确定性作为伴随的概率值包含在内。例如，项目有 90% 的概率会在确定日期或之前完成。

• 组织不收集准确的项目数据。由于估计的准确性取决于历史数据，因此这将是一个问题。

• 对于任何项目，都有一个尽可能短的时间表，使您能够包含所需的功能并产生高质量的输出。如果管理层和/或客户有进度限制，您可以就要交付的范围和功能进行协商。

• 与客户就处理范围蔓延达成一致，以避免进度超支。

• 最终估算中未能考虑到意外情况会导致问题。例如，会议、组织活动。

• 资源利用率应视为低于 80%。这是因为资源只能在 80% 的时间内发挥生产力。如果您以超过 80% 的利用率分配资源，必然会出现延误。

估算指南

在评估项目时应牢记以下准则 -

• 在估算时，询问其他人的经验。另外，将您自己的经验用于任务中。

• 假设资源只有 80% 的时间是高效的。因此，估算时取资源利用率低于80%。

• 由于在多个项目之间切换所浪费的时间，处理多个项目的资源需要更长的时间才能完成任务。

• 在任何估计中都包括管理时间。

• 始终为解决问题、会议和其他意外事件做好准备。

• 留出足够的时间进行适当的项目估算。仓促的估计是不准确的、高风险的估计。对于大型开发项目，估算步骤实际上应该被视为一个小型项目。

• 如果可能，请使用组织过去类似项目的记录数据。它将产生最准确的估计。如果您的组织没有保留历史数据，那么现在是开始收集历史数据的好时机。

• 使用基于开发人员的估算，因为由执行该工作的人员以外的人准备的估算将不太准确。

• 使用几个不同的人来估计并使用几种不同的估计技术。

• 核对估计值。观察估计值之间的收敛或分散。收敛意味着您获得了良好的估计。宽带德尔菲技术可用于让一群人收集和讨论估计值，目的是产生准确、公正的估计值。

• 在项目的整个生命周期中多次重新评估项目。

估计技术 - 功能点

功能点(FP) 是一种衡量单位，用于表达信息系统（作为产品）向用户提供的业务功能量。FP 测量软件大小。它们被广泛接受为功能性尺寸的行业标准。

对于基于 FP 的规模调整软件，已经出现了一些公认的标准和/或公共规范。截至 2013 年，这些是 -

国际标准化组织标准

• COSMIC - ISO/IEC 19761:2011 软件工程。一种功能性尺寸测量方法。

• FiSMA - ISO/IEC 29881:2008 信息技术 - 软件和系统工程 - FiSMA 1.1 功能尺寸测量方法。

• IFPUG - ISO/IEC 20926:2009 软件和系统工程 - 软件测量 - IFPUG 功能尺寸测量方法。

• Mark-II - ISO/IEC 20968:2002 软件工程 - Ml II 功能点分析 - 计数实践手册。

• NESMA - ISO/IEC 24570:2005 软件工程 - NESMA 功能大小测量方法版本 2.1 - 功能点分析应用的定义和计数指南。

自动化功能点的对象管理组规范

对象管理组 (OMG) 是一个开放会员制、非营利性的计算机行业标准联盟，已采用由 IT 软件质量联盟领导的自动化功能点 (AFP) 规范。它根据国际功能点用户组 (IFPUG) 的指南提供了自动 FP 计数的标准。

功能点分析 (FPA) 技术以对软件用户有意义的方式量化软件中包含的功能。FP 根据需求规范考虑正在开发的功能数量。

功能点 (FP) 计数受国际功能点用户组 (IFPUG) 定义的一组标准规则、流程和指南管辖。这些内容发布在《计数实践手册》(CPM) 中。

功能点分析的历史

功能点的概念是由 IBM 的 Alan Albrecht 于 1979 年提出的。1984 年，Albrecht 改进了该方法。第一份功能点指南于 1984 年发布。国际功能点用户组 (IFPUG) 是一个总部位于美国的全球功能点分析度量软件用户组织。国际功能点用户组 (IFPUG)是一个成立于 1986 年的非营利性会员管理组织。IFPUG 拥有 ISO 标准 20296:2009 中定义的功能点分析 (FPA)，该标准规定了应用功能点分析的定义、规则和步骤。 IFPUG 的功能尺寸测量（FSM）方法。IFPUG 维护功能点计数实践手册 (CPM)。CPM 2.0于1987年发布，此后又经历了多次迭代。CPM 版本 4.3 于 2010 年发布。

包含 ISO 编辑修订的 CPM 版本 4.3.1 于 2010 年发布。ISO 标准 (IFPUG FSM) - 功能规模测量是 CPM 4.3.1 的一部分，是一种根据软件提供的功能来测量软件的技术。CPM 是 ISO/IEC 14143-1 信息技术 – 软件测量下的国际认可标准。

基本过程 (EP)

基本流程是功能用户需求的最小单位：

• 对用户有意义。
• 构成一次完整的交易。
• 是独立的，并且使应用程序的业务以一致的状态进行计数。

功能

有两种类型的函数 -

• 数据功能
• 交易功能

数据功能

有两种类型的数据函数 -

• 内部逻辑文件
• 外部接口文件

数据功能由影响系统的内部和外部资源组成。

内部逻辑文件

内部逻辑文件 (ILF) 是一组用户可识别的逻辑相关数据或控制信息，完全驻留在应用程序边界内。ILF 的主要目的是保存通过正在计数的应用程序的一个或多个基本进程维护的数据。ILF 具有内在含义，即它是内部维护的，它具有某种逻辑结构并且存储在文件中。（见图1）

外部接口文件

外部接口文件 (EIF) 是用户可识别的逻辑相关数据或控制信息组，应用程序仅将其用于参考目的。数据完全驻留在应用程序边界之外，并由另一个应用程序在 ILF 中维护。EIF 的固有含义是它是外部维护的，必须开发一个接口来从文件中获取数据。（见图1）

交易功能

交易功能分为三种类型。

• 外部输入
• 外部输出
• 外部查询

事务功能由用户、外部应用程序和被测量的应用程序之间交换的过程组成。

外部输入

外部输入 (EI) 是一种事务功能，其中数据从边界外部到内部“进入”应用程序。该数据来自应用程序外部。

• 数据可能来自数据输入屏幕或其他应用程序。
• EI 是应用程序获取信息的方式。
• 数据可以是控制信息或业务信息。
• 数据可用于维护一个或多个内部逻辑文件。
• 如果数据是控制信息，则不必更新内部逻辑文件。（见图1）

外部输出

外部输出 (EO) 是一种事务功能，其中数据从系统“输出”。此外，EO 可以更新 ILF。数据创建发送到其他应用程序的报告或输出文件。（见图1）

外部查询

外部查询 (EQ) 是一种事务功能，具有导致数据检索的输入和输出组件。（见图1）

RET、DET、FTR 的定义

记录元素类型

记录元素类型 (RET) 是 ILF 或 EIF 中最大的用户可识别元素子组。最好查看数据的逻辑分组以帮助识别它们。

数据元素类型

数据元素类型 (DET) 是 FTR 中的数据子组。它们是唯一的且用户可识别的。

引用的文件类型

引用的文件类型 (FTR) 是引用的 EI、EO 或 EQ 中最大的用户可识别子组。

交易函数EI、EO、EQ是通过计算它们包含的以下计数规则的FTR和DET来测量的。同样，数据函数ILF和EIF是通过计算它们包含的以下计数规则的DET和RET来测量的。交易功能和数据功能的度量用于FP计数，从而得出功能大小或功能点。

估计技术 - FP 计数过程

FP 计数过程涉及以下步骤 -

• 步骤 1 - 确定计数类型。

• 步骤 2 - 确定计数的边界。

• 步骤 3 - 确定用户所需的每个基本流程 (EP)。

• 步骤 4 - 确定唯一的 EP。

• 步骤 5 - 测量数据函数。

• 步骤 6 - 衡量交易功能。

• 步骤 7 - 计算功能规模（未调整的功能点数）。

• 步骤 8 - 确定值调整因子 (VAF)。

• 步骤 9 - 计算调整后的功能点数量。

注- 一般系统特性 (GSC) 在 CPM 4.3.1 中为可选，并移至附录。因此，可以跳过步骤8和步骤9。

步骤 1：确定计数类型

功能点计数分为三种类型 -

• 开发功能点数
• 应用功能点数
• 增强功能点数

开发功能点数

功能点可以在开发项目从需求阶段到实施阶段的所有阶段进行计数。这种类型的计数与新的开发工作相关联，并且可能包括原型，该原型可能需要作为临时解决方案，以支持转换工作。这种类型的计数称为基线功能点计数。

应用功能点数

应用程序计数按交付的功能点计算，不包括任何转换工作（原型或临时解决方案）和可能已存在的现有功能。

增强功能点数

当软件在生产后进行更改时，它们被视为增强。为了确定此类增强项目的规模，需要在应用程序中添加、更改或删除功能点计数。

步骤 2：确定计数的边界

边界表示被测量的应用程序与外部应用程序或用户域之间的边界。（见图1）

要确定边界，请理解 -

• 功能点计数的目的
• 正在测量的应用范围
• 如何以及哪些应用程序维护哪些数据
• 支持应用程序的业务领域

第 3 步：确定用户所需的每个基本流程

将功能用户需求组合和/或分解为最小的活动单元，满足以下所有标准 -

• 对用户有意义。
• 构成一次完整的交易。
• 是独立的。
• 使应用程序的业务保持一致的状态。

例如，功能用户需求-“维护员工信息”可以分解为更小的活动，例如添加员工、更改员工、删除员工和查询员工。

由此确定的每个活动单元都是一个基本过程 (EP)。

步骤 4：确定独特的基本过程

比较已识别的两个 EP，如果它们 -

• 需要同一组 DET。
• 需要相同的 FTR 集。
• 需要同一套处理逻辑来完成EP。

不要将具有多种处理逻辑形式的 EP 拆分为多个 Ep。

例如，如果您已将“添加员工”标识为 EP，则不应将其分为两个 EP 来考虑员工可能有或没有家属的事实。EP 仍然是“添加员工”，并且处理逻辑和 DET 有所不同，以考虑家属。

第 5 步：测量数据函数

将每个数据函数分类为 ILF 或 EIF。

数据功能应分类为 -

• 内部逻辑文件 (ILF)，如果它由正在测量的应用程序维护。

• 外部接口文件 (EIF)（如果被测量的应用程序引用但不维护）。

ILF 和 EIF 可以包含业务数据、控制数据和基于规则的数据。例如，电话交换由所有三种类型组成：业务数据、规则数据和控制数据。业务数据才是实际的调用。规则数据是呼叫应如何通过网络路由，控制数据是交换机如何相互通信。

请考虑以下用于计算 ILF 和 EIF 的文档 -

• 拟议系统的目标和限制。
• 有关当前系统的文档（如果存在这样的系统）。
• 用户感知的目标、问题和需求的文档。
• 数据模型。

步骤 5.1：计算每个数据函数的 DET

应用以下规则来计算 ILF/EIF 的 DET -

• 为通过执行 EP 在 ILF 或 EIF 中维护或检索的每个唯一用户可识别、非重复字段计算 DET。

• 仅计算当两个或多个应用程序维护和/或引用相同数据函数时测量的应用程序正在使用的那些 DET。

• 为用户与另一个ILF或EIF建立关系所需的每个属性计算一个DET。

• 查看相关属性以确定它们是分组并计为单个 DET 还是计为多个 DET。分组将取决于 EP 如何在应用程序中使用属性。

步骤 5.2：计算每个数据函数的 RET

应用以下规则来计算 ILF/EIF 的 RET -

• 为每个数据函数计算一个 RET。
• 为以下每个额外的 DET 逻辑子组计算一个额外的 RET。
  • 具有非键属性的关联实体。
  • 子类型（第一个子类型除外）。
  • 归属实体，处于非强制性 1:1 关系。

步骤 5.3：确定每个数据功能的功能复杂性

功能复杂性：L = 低；A = 平均值；H = 高

步骤 5.4：测量每个数据函数的函数大小

第 6 步：衡量交易功能

要衡量交易功能，以下是必要的步骤 -

步骤 6.1：对每个事务功能进行分类

事务功能应分类为外部输入、外部输出或外部查询。

外部输入

外部输入 (EI) 是处理来自边界外部的数据或控制信息的基本过程。EI 的主要目的是维护一个或多个 ILF 和/或改变系统的Behave。

必须应用以下所有规则 -

• 数据或控制信息是从应用程序边界外部接收的。

• 如果进入边界的数据不是改变系统Behave的控制信息，则至少维持一个ILF。

• 对于已确定的 EP，必须适用以下三个声明之一 -

  • 处理逻辑不同于其他 EI 为该应用程序执行的处理逻辑。

  • 所识别的数据元素集不同于为应用程序中的其他 EI 所识别的数据元素集。

  • 引用的 ILF 或 EIF 与应用程序中其他 EI 引用的文件不同。

外部输出

外部输出 (EO) 是向应用程序边界之外发送数据或控制信息的基本进程。EO 包括外部询问之外的额外处理。

EO 的主要目的是通过除数据或控制信息检索之外的处理逻辑向用户呈现信息。

处理逻辑必须 -

• 包含至少一个数学公式或计算。
• 创建派生数据。
• 维护一个或多个 ILF。
• 改变系统的Behave。

必须应用以下所有规则 -

• 将数据或控制信息发送到应用程序边界外部。
• 对于已确定的 EP，必须适用以下三个声明之一 -
  • 处理逻辑与其他 EO 为该应用程序执行的处理逻辑是不同的。
  • 所识别的数据元素集与应用程序中的其他 EO 不同。
  • 引用的 ILF 或 EIF 与应用程序中其他 EO 引用的文件不同。

此外，必须适用以下规则之一 -

• 处理逻辑包含至少一个数学公式或计算。
• 处理逻辑维护至少一个ILF。
• 处理逻辑改变系统的Behave。

外部询价

外部查询 (EQ) 是一个向边界之外发送数据或控制信息的基本过程。EQ 的主要目的是通过检索数据或控制信息向用户呈现信息。

处理逻辑不包含数学公式或计算，并且不创建派生数据。处理期间不会维护 ILF，系统的Behave也不会改变。

必须应用以下所有规则 -

• 将数据或控制信息发送到应用程序边界外部。
• 对于已确定的 EP，必须适用以下三个声明之一 -
  • 处理逻辑不同于应用程序的其他均衡器执行的处理逻辑。
  • 所识别的数据元素集与应用程序中的其他 EQ 不同。
  • 引用的 ILF 或 EIF 与应用程序中其他 EQ 引用的文件不同。

此外，以下所有规则必须适用 -

• 处理逻辑从 ILF 或 EIF 检索数据或控制信息。
• 处理逻辑不包含数学公式或计算。
• 处理逻辑不会改变系统的Behave。
• 处理逻辑不维护 ILF。

步骤 6.2：计算每个事务功能的 DET

应用以下规则来计算 EI 的 DET -

• 检查跨越（进入和/或退出）边界的所有内容。

• 对于在处理事务功能期间跨越（进入和/或退出）边界的每个唯一的用户可识别的、非重复的属性，计算一个DET。

• 即使存在多条消息，每个事务功能也仅计算一个 DET，以便能够发送应用程序响应消息。

• 即使有多种方法可以启动操作，每个事务功能也仅计算一个 DET。

• 不要将以下项目算作 DET -

  • 由事务功能在边界内生成并保存到 ILF 而不退出边界的属性。

  • 文字，例如报表标题、屏幕或面板标识符、列标题和属性标题。

  • 应用程序生成的标记，例如日期和时间属性。

  • 分页变量、页码和定位信息，例如“211 的第 37 至 54 行”。

  • 导航辅助，例如使用“上一个”、“下一个”、“第一个”、“最后一个”及其图形等效项在列表中导航的能力。

应用以下规则来计算 EO/EQ 的 DET -

• 检查跨越（进入和/或退出）边界的所有内容。

• 对于在处理事务功能期间跨越（进入和/或退出）边界的每个唯一的用户可识别的、非重复的属性，计算一个DET。

• 即使存在多条消息，每个事务功能也仅计算一个 DET，以便能够发送应用程序响应消息。

• 即使有多种方法可以启动操作，每个事务功能也仅计算一个 DET。

• 不要将以下项目算作 DET -

  • 属性在边界内生成，不跨越边界。

  • 文字，例如报表标题、屏幕或面板标识符、列标题和属性标题。

  • 应用程序生成的标记，例如日期和时间属性。

  • 分页变量、页码和定位信息，例如“211 的第 37 至 54 行”。

  • 导航辅助，例如使用“上一个”、“下一个”、“第一个”、“最后一个”及其图形等效项在列表中导航的能力。

步骤 6.3：计算每个事务功能的 FTR

应用以下规则来计算 EI 的 FTR -

• 为每个维护的 ILF 计算一个 FTR。
• 计算 EI 处理期间每个 ILF 或 EIF 读取的 FTR。
• 对于维护和读取的每个 ILF 仅计算一个 FTR。

应用以下规则来计算 EO/EQ 的 FTR -

• 在 EP 处理期间对每个 ILF 或 EIF 读取计数一个 FTR。

此外，应用以下规则来计算 EO 的 FTR -

• 为 EP 处理期间维护的每个 ILF 计算一个 FTR。
• 对于由 EP 维护和读取的每个 ILF，仅计算一个 FTR。

步骤 6.4：确定每个事务功能的功能复杂性

功能复杂性：L = 低；A = 平均值；H = 高

确定每个 EO/EQ 的功能复杂性，但 EQ 必须至少具有 1 FTR -

功能复杂性：L = 低；A = 平均值；H = 高

步骤 6.5：测量每个事务功能的功能规模

根据每个 EI 的功能复杂性来衡量其功能规模。

根据每个 EO/EQ 的功能复杂性来衡量其功能规模。

步骤 7：计算功能规模（未调整的功能点数）

要计算功能大小，应遵循以下步骤 -

步骤7.1

回忆一下您在步骤 1 中发现的内容。确定计数类型。

步骤7.2

根据类型计算功能规模或功能点数。

• 开发功能点统计请参见步骤7.3。
• 应用功能点计数请参见步骤7.4。
• 对于增强功能点计数，请转至步骤 7.5。

步骤7.3

开发功能点计数由两个功能组成部分组成 -

• 应用程序功能包含在项目的用户需求中。

• 转换功能包含在项目的用户需求中。转换功能由仅在安装时提供的功能组成，用于转换数据和/或提供其他用户指定的转换要求，例如特殊转换报告。例如，现有的应用程序可能会被新系统替换。

DFP = 添加 + CFP

在哪里，

DFP = 开发功能点数

ADD = 开发项目交付给用户的功能大小

CFP = 转换功能的大小

ADD = FP 计数 (ILF) + FP 计数 (EIF) + FP 计数 (EI) + FP 计数 (EO) + FP 计数 (EQ)

CFP = FP 计数 (ILF) + FP 计数 (EIF) + FP 计数 (EI) + FP 计数 (EO) + FP 计数 (EQ)

步骤7.4

计算应用功能点数

法新社=添加

在哪里，

AFP = 应用功能点数

ADD = 开发项目交付给用户的功能大小（不包括任何转换功能的大小），或计算应用程序时存在的功能。

ADD = FP 计数 (ILF) + FP 计数 (EIF) + FP 计数 (EI) + FP 计数 (EO) + FP 计数 (EQ)

步骤7.5

增强功能点计数考虑以下四个功能组成部分 -

• 添加到应用程序的功能。
• 应用程序中修改的功能。
• 转换功能。
• 从应用程序中删除的功能。

EFP = 添加 + CHGA + CFP + 删除

在哪里，

EFP = 增强功能点数

ADD = 增强项目添加的功能规模

CHGA = 增强项目改变的功能规模

CFP = 转换功能的大小

DEL = 增强项目删除的功能大小

ADD = FP 计数 (ILF) + FP 计数 (EIF) + FP 计数 (EI) + FP 计数 (EO) + FP 计数 (EQ)

CHGA = FP 计数 (ILF) + FP 计数 (EIF) + FP 计数 (EI) + FP 计数 (EO) + FP 计数 (EQ)

CFP = FP 计数 (ILF) + FP 计数 (EIF) + FP 计数 (EI) + FP 计数 (EO) + FP 计数 (EQ)

DEL = FP 计数 (ILF) + FP 计数 (EIF) + FP 计数 (EI) + FP 计数 (EO) + FP 计数 (EQ)

步骤8：确定数值调整系数

GSC 在 CPM 4.3.1 中成为可选的，并移至附录。因此，可以跳过步骤8和步骤9。

价值调整因子 (VAF) 基于 14 个 GSC，这些 GSC 对所统计的应用程序的一般功能进行评级。GSC 是独立于技术的用户业务约束。每个特征都有相关的描述来确定影响程度。

影响程度范围为0到5，从无影响到有强影响。

确定 14 个 GSC 中每一个的影响程度。

由此获得的 14 个 GSC 值的总和称为总影响度 (TDI)。

TDI = Σ ¹⁴影响度

接下来，计算价值调整因子 (VAF)：

VAF=(TDI×0.01)+0.65

每个 GSC 的变化范围为 0 到 5，TDI 的变化范围为 (0 × 14) 到 (5 × 14)，即 0（当所有 GSC 都为低时）到 70（当所有 GSC 都为高时），即 0 ≤ TDI ≤ 70。因此，VAF 的变化范围为 0.65（当所有 GSC 都较低时）到 1.35（当所有 GSC 都较高时），即 0.65 ≤ VAF ≤ 1.35。

步骤9：计算调整后的功能点数

根据使用 VAF 的 FPA 方法（V4.3.1 之前的 CPM 版本），这是由以下因素决定的：

调整后的 FP 计数 = 未调整的 FP 计数 × VAF

其中，未调整的 FP 计数是您在步骤 7 中计算的函数大小。

由于 VAF 的变化范围为 0.65 至 1.35，因此 VAF 对最终调整后的 FP 计数产生 ±35% 的影响。

功能点的好处

功能点很有用 -

• 衡量解决方案的大小而不是问题的大小。

• 因为需求是功能点计数所需的唯一内容。

• 因为它独立于技术。

• 因为它独立于编程语言。

• 在评估测试项目时。

• 估算总体项目成本、进度和工作量。

• 在合同谈判中，它提供了一种更容易与业务团体沟通的方法。

• 因为它对软件中功能的实际用途、接口和目的进行量化和赋值。

• 与其他指标（例如工时、成本、人数、持续时间和其他应用程序指标）创建比率。

FP 存储库

国际软件基准测试标准组织 (ISBSG) 发展并维护两个 IT 数据存储库。

• 发展及提升项目
• 维护和支持应用程序

开发和增强项目存储库中有 6,000 多个项目。

数据以 Microsoft Excel 格式提供，使您可以更轻松地进行进一步分析，甚至可以将数据用于其他目的。

ISBSG 存储库许可证可以从以下位置购买：http://www.isbsg.com/

ISBSG 为 IFPUG 会员提供 10% 折扣，使用折扣码“IFPUGMembers”进行网上购物。

ISBSG 软件项目数据发布更新可在以下位置找到：http://www.ifpug.org/isbsg/

COSMIC 和 IFPUG 合作制定了软件非功能和项目需求术语表。可以从 - cosmic-sizing.org下载

估计技术 - 用例点

用例是用户和系统之间的一系列相关交互，使用户能够实现目标。

用例是捕获系统功能需求的一种方法。系统的用户被称为“参与者”。用例基本上是文本形式。

用例点 – 定义

用例点（UCP）是一种软件估计技术，用于通过用例来衡量软件大小。UCP的概念与FP类似。

项目中 UCP 的数量基于以下因素 -

• 系统中用例的数量和复杂性。
• 系统中参与者的数量和复杂性。

  • 未编写为用例的各种非功能性需求（例如可移植性、性能、可维护性）。

  • 项目将要开发的环境（例如语言、团队的动机等）

使用 UCP 进行估计要求所有用例都以目标和大致相同的级别编写，并提供相同数量的细节。因此，在估计之前，项目团队应确保他们已经以明确的目标和详细程度编写了用例。用例通常在单个会话内完成，在实现目标后，用户可以继续进行其他一些活动。

用例点的历史

用例点估计方法由 Gustav Karner 于 1993 年提出。这项工作后来获得了并入 IBM 的 Rational Software 的许可。

用例点计数过程

用例点计数过程有以下步骤 -

• 计算未调整的 UCP
• 根据技术复杂性进行调整
• 根据环境复杂性进行调整
• 计算调整后的 UCP

步骤 1：计算未调整的用例点。

您首先通过以下步骤计算未调整的用例点 -

• 确定未调整的用例权重
• 确定未调整的演员体重
• 计算未调整的用例点

步骤 1.1 - 确定未调整的用例权重。

步骤 1.1.1 - 查找每个用例中的交易数量。

如果用例是用用户目标级别编写的，则事务相当于用例中的一个步骤。通过计算用例中的步骤来查找事务数。

步骤 1.1.2 - 根据用例中的事务数量将每个用例分类为简单、平均或复杂。另外，分配用例权重，如下表所示 -

步骤 1.1.3 - 对每个用例重复并获取所有用例权重。未调整用例权重 (UUCW) 是所有用例权重的总和。

步骤 1.1.4 - 使用下表查找未调整用例权重 (UUCW) -

在哪里，

NSUC 是第一。简单用例。

NAUC 是第一。平均用例。

NCUC 是第一。复杂的用例。

步骤 1.2 - 确定未调整的演员体重。

用例中的参与者可能是一个人、另一个程序等。某些参与者（例如具有定义的 API 的系统）具有非常简单的需求，并且只会稍微增加用例的复杂性。

一些参与者，例如通过协议交互的系统有更多的需求，并在一定程度上增加了用例的复杂性。

其他参与者（例如通过 GUI 交互的用户）对用例的复杂性有重大影响。根据这些差异，您可以将参与者分为简单、一般和复杂。

步骤 1.2.1 - 将演员分类为简单、平均和复杂，并分配演员权重，如下表所示 -

步骤 1.2.2 - 对每个演员重复并获取所有演员权重。未调整演员权重 (UAW) 是所有演员权重的总和。

步骤1.2.3 - 使用下表查找未调整的演员体重（UAW） -

在哪里，

美国国家安全局是第一。简单的演员。

NAA 是第一。平均演员。

NCA 是第一。复杂的演员。

步骤 1.3 - 计算未调整的用例点。

未调整用例权重 (UUCW) 和未调整参与者权重 (UAW) 共同给出了系统的未调整大小，称为未调整用例点。

未调整用例点 (UUCP) = UUCW + UAW

接下来的步骤是调整技术复杂性和环境复杂性的未调整用例点 (UUCP)。

第 2 步：根据技术复杂性进行调整

步骤 2.1 - 考虑导致项目技术复杂性对用例点影响的 13 个因素及其相应的权重，如下表所示 -

其中许多因素代表了项目的非功能性需求。

步骤 2.2 - 对于 13 个因素中的每一个，评估项目并从 0（不相关）到 5（非常重要）进行评分。

步骤 2.3 - 根据因素的影响权重和项目的额定值计算因素的影响：

因素影响力=影响权重×额定值

步骤 (2.4) - 计算所有因素的影响力之和。这给出了总技术系数（TFactor），如下表所示 -

步骤 2.5 - 将技术复杂度因子 (TCF) 计算为 -

TCF = 0.6 + (0.01 × T 因子)

第 3 步：根据环境复杂性进行调整

步骤 3.1 - 考虑可能影响项目执行的 8 个环境因素及其相应的权重，如下表所示 -

步骤 3.2 - 对于 8 个因素中的每一个，评估项目并从 0（不相关）到 5（非常重要）进行评分。

步骤 3.3 - 根据因素的影响权重和项目的额定值计算因素的影响：

因素影响力=影响权重×额定值

步骤 3.4 - 计算所有因素影响的总和。这给出了总环境因子（EFactor），如下表所示 -

步骤 3.5 - 将环境因素 (EF) 计算为 -

1.4 + (-0.03 × E 系数)

步骤 4：计算调整后的用例点 (UCP)

将调整后的用例点 (UCP) 计算为 -

UCP = UUCP × TCF × EF

用例点的优点和缺点

用例点的优点

• UCP 基于用例，可以在项目生命周期的早期进行测量。

• UCP（规模估算）将独立于实施项目的团队的规模、技能和经验。

• 当由经验丰富的人员进行估算时，发现基于 UCP 的估算值接近实际值。

• UCP 易于使用，不需要额外的分析。

• 用例被广泛用作描述需求的一种选择方法。在这种情况下，UCP 是最合适的估计技术。

用例点的缺点

• 只有当需求以用例的形式编写时才能使用 UCP。

• 依赖于以目标为导向、编写良好的用例。如果用例的结构不良好或不统一，则生成的 UCP 可能不准确。

• 技术和环境因素对 UCP 有很大影响。在为技术和环境因素赋值时需要小心。

• UCP 对于总体项目规模的初步估计很有用，但在推动团队的迭代工作方面却不太有用。

估计技术 - Wideband Delphi

德尔菲法是一种结构化沟通技术，最初是作为一种依赖于专家小组的系统性、交互式预测方法而开发的。专家分两轮或以上回答问卷。每轮结束后，主持人都会对上一轮专家的预测进行匿名总结，并附上他们的判断理由。然后鼓励专家根据小组其他成员的答复修改他们之前的答案。

人们相信，在这个过程中，答案的范围将会缩小，并且小组将向“正确”答案靠拢。最后，在达到预定义的停止标准（例如轮数、达成共识和结果的稳定性）后停止该过程，最后轮次的平均分或中位数决定结果。

德尔菲法是兰德公司在 1950-1960 年代开发的。

宽带德尔菲技术

20 世纪 70 年代，Barry Boehm 和 John A. Farquhar 发明了德尔菲法的宽带变体。使用“宽带”一词是因为，与德尔菲法相比，宽带德尔菲技术涉及参与者之间更多的互动和交流。

在宽带德尔菲技术中，估算团队由项目经理、主持人、专家以及开发团队的代表组成，组成3-7人的团队。有两次会议 -

• 启动大会
• 评估会议

宽带德尔福技术 – 步骤

步骤 1 - 选择评估团队和主持人。

步骤 2 - 主持人主持启动会议，向团队展示问题规范和高级任务列表、任何假设或项目限制。团队讨论问题和估计问题（如果有）。他们还决定估计单位。主持人指导整个讨论，监控时间，并在启动会议后准备一份结构化文件，其中包含问题说明、高级任务列表、假设和所决定的估计单位。然后，他转发该文件的副本以供下一步使用。

步骤 3 - 然后，每个估算团队成员单独生成详细的 WBS，估算 WBS 中的每项任务，并记录所做的假设。

步骤 4 - 主持人召集估算团队召开估算会议。如果任何估算团队成员回复说估算尚未准备好，主持人会给予更多时间并重新发送会议邀请。

步骤 5 - 整个估算团队聚集在一起参加估算会议。

步骤 5.1 - 在估算会议开始时，主持人收集每个团队成员的初步估算。