估算技术速查

---

---

估算技术 - 概述

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

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

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

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

• 估算开发产品的规模。
• 估算以人月或人时为单位的工作量。
• 估算以日历月为单位的进度。
• 估算以约定的货币为单位的项目成本。

关于估算的观察

• 估算不必是项目中的一次性任务。它可以在以下阶段进行：

  • 获取项目。
  • 计划项目。
  • 根据需要执行项目。

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

• 项目指标可以提供历史视角和生成定量估算的宝贵输入。

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

• 过去的经验可以极大地帮助。

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

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

通用项目估算方法

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

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

步骤 2 - 生成软件规模的估算。

• 从范围说明开始。

• 将软件分解成可以分别估算的各个功能。

• 计算每个功能的规模。

• 通过将规模值应用于您的基线生产力指标来推导出工作量和成本估算。

• 组合功能估算以生成整个项目的总体估算。

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

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

• 将活动分解成可以衡量的任务。

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

• 组合活动任务的工作量估算以生成该活动的估算。

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

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

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

步骤 4 - 协调估算：将步骤 3 中的结果值与步骤 2 中获得的结果值进行比较。如果两组估算值一致，则您的数字非常可靠。否则，如果出现差异很大的估算值，则应进一步调查以下问题：

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

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

• 用于估算技术的历史数据不适用于该应用程序，或已过时，或已被误用。

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

Explore our latest online courses and learn new skills at your own pace. Enroll and become a certified expert to boost your career.

估算精度

精度是指某事物与现实有多接近的指标。每当您生成估算值时，每个人都想知道这些数字与现实有多接近。您希望在生成估算值时，根据当时拥有的数据，每个估算值都尽可能准确。当然，您不希望以一种会让人对数字产生错误的信心感的方式来呈现估算值。

影响估算精度的重要因素包括：

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

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

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

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

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

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

以下是实现可靠估算的一些指南：

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

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

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

估算问题

通常，项目经理会采用跳过规模估算而直接估算进度的做法。这可能是由于高层管理或营销团队设定的时间表所致。但是，无论原因是什么，如果这样做，那么在后期阶段，要估算进度以适应范围变更将会非常困难。

在估算过程中，可能会做出某些假设。重要的是在估算表中记录所有这些假设，因为有些人仍然不会在估算表中记录假设。

即使是良好的估算也存在固有的假设、风险和不确定性，但它们通常却被视为准确的。

表达估算的最佳方式是作为一系列可能的结果，例如，说项目将需要 5 到 7 个月，而不是说它将在特定日期完成或将在固定数量的月份内完成。要注意避免承诺过于狭窄的范围，因为这等同于承诺一个确定的日期。

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

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

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

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

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

• 资源利用率应考虑小于 80%。这是因为资源只有 80% 的时间才能有效率。如果您分配的资源利用率超过 80%，则必然会发生延误。

估算指南

在估算项目时，应牢记以下指南：

• 在估算过程中，询问其他人的经验。此外，也要运用你自己的经验。

• 假设资源只有 80% 的时间才能有效率。因此，在估算过程中，将资源利用率设定为低于 80%。

• 同时参与多个项目的资源由于在项目之间切换而花费的时间损失，导致完成任务所需的时间更长。

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

• 始终为解决问题、会议和其他意外事件留出足够的时间。

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

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

• 使用基于开发人员的估算，因为由非执行人员编制的估算将不太准确。

• 使用几个人进行估算，并使用几种不同的估算技术。

• 协调估算。观察估算结果的收敛或差异。收敛意味着您已经获得了一个良好的估算。宽带德尔菲法可用于使用一群人收集和讨论估算，其目的是产生准确、无偏见的估算。

• 在项目生命周期的多个时间点重新估算项目。

估算技术 - 功能点

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

对于基于 FP 的软件规模计算，已经出现了一些公认的标准和/或公共规范。截至 2013 年，这些标准包括：

ISO 标准

• 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) 自动化功能点规范

对象管理组织 (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 - 计算调整后的函数点计数。

注意 - CPM 4.3.1中通用系统特性 (GSCs) 变为可选，并移至附录。因此，可以跳过步骤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 和/或改变系统的行为。

必须应用以下所有规则：

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

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

• 对于已识别的基本过程 (EP)，必须应用以下三个陈述之一：

  • 处理逻辑与应用程序中其他 EI 执行的处理逻辑不同。

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

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

外部输出

外部输出 (EO) 是一个基本过程，它将数据或控制信息发送到应用程序边界之外。EO 包括超出外部查询的额外处理。

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

处理逻辑必须：

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

必须应用以下所有规则：

• 将数据或控制信息发送到应用程序边界之外。
• 对于已识别的基本过程 (EP)，必须应用以下三个陈述之一：
  • 处理逻辑与应用程序中其他 EO 执行的处理逻辑不同。
  • 已识别的的数据元素集与应用程序中其他 EO 的数据元素集不同。
  • 引用的 ILF 或 EIF 与应用程序中其他 EO 引用的文件不同。

此外，必须应用以下规则之一：

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

外部查询

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

处理逻辑不包含数学公式或计算，也不创建派生数据。在处理过程中不维护任何 ILF，也不改变系统的行为。

必须应用以下所有规则：

• 将数据或控制信息发送到应用程序边界之外。
• 对于已识别的基本过程 (EP)，必须应用以下三个陈述之一：
  • 处理逻辑与应用程序中其他 EQ 执行的处理逻辑不同。
  • 已识别的的数据元素集与应用程序中其他 EQ 的数据元素集不同。
  • 引用的 ILF 或 EIF 与应用程序中其他 EQ 引用的文件不同。

此外，必须应用以下所有规则：

• 处理逻辑从 ILF 或 EIF 检索数据或控制信息。
• 处理逻辑不包含数学公式或计算。
• 处理逻辑不改变系统的行为。
• 处理逻辑不维护 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 = ADD + CFP

其中：

DFP = 开发功能点计数

ADD = 开发项目交付给用户的函数规模

CFP = 转换功能的规模

ADD = ILF 功能点数 + EIF 功能点数 + EI 功能点数 + EO 功能点数 + EQ 功能点数

CFP = ILF 功能点数 + EIF 功能点数 + EI 功能点数 + EO 功能点数 + EQ 功能点数

步骤 7.4

计算应用程序功能点计数

AFP = ADD

其中：

AFP = 应用程序功能点计数

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

ADD = ILF 功能点数 + EIF 功能点数 + EI 功能点数 + EO 功能点数 + EQ 功能点数

步骤 7.5

增强功能点计数考虑以下四个功能组件：

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

EFP = ADD + CHGA + CFP + DEL

其中：

EFP = 增强功能点计数

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

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

CFP = 转换功能的规模

DEL = 增强项目删除的功能规模

ADD = ILF 功能点数 + EIF 功能点数 + EI 功能点数 + EO 功能点数 + EQ 功能点数

CHGA = ILF 功能点数 + EIF 功能点数 + EI 功能点数 + EO 功能点数 + EQ 功能点数

CFP = ILF 功能点数 + EIF 功能点数 + EI 功能点数 + EO 功能点数 + EQ 功能点数

DEL = ILF 功能点数 + EIF 功能点数 + EI 功能点数 + EO 功能点数 + EQ 功能点数

步骤 8：确定价值调整因子

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

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

影响程度范围为零到五，从无影响到强烈影响。

确定每个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的功能点分析法（V4.3.1之前的CPM版本），这是由以下公式确定的：

调整后的功能点计数 = 未调整的功能点计数 × VAF

其中，未调整的功能点计数是在步骤7中计算的功能规模。

由于VAF可以在0.65到1.35之间变化，因此VAF对最终调整后的功能点计数的影响为±35%。

功能点的优势

功能点很有用，因为：

• 用于衡量解决方案的规模，而不是问题的规模。

• 因为只需要需求就能计算功能点。

• 因为它独立于技术。

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

• 用于估算测试项目。

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

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

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

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

功能点库

国际软件基准标准组织（ISBSG）建立并维护两个IT数据存储库。

• 开发和增强项目
• 维护和支持应用程序

开发和增强项目存储库中包含6000多个项目。

数据以Microsoft Excel格式提供，方便您进行进一步分析，或者您可以将数据用于其他目的。

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

ISBSG为IFPUG会员提供在线购买10%的折扣，使用折扣码“IFPUGMembers”。

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

COSMIC和IFPUG合作编写了软件非功能性和项目需求术语表。可从此处下载：cosmic-sizing.org

估算技术 - 用例点

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

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

用例点 – 定义

用例点（UCP）是一种软件估算技术，用于使用用例衡量软件规模。UCP的概念类似于功能点。

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

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

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

  • 项目将要开发的环境（例如语言、团队的积极性等）。

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

用例点历史

用例点估算方法由Gustav Karner于1993年提出。这项工作后来被Rational Software授权，后者并入IBM。

用例点计数过程

用例点计数过程包含以下步骤：

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

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

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

• 确定未调整的用例权重
• 确定未调整的参与者权重
• 计算未调整的用例点

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

步骤1.1.1 – 查找每个用例中的事务数量。

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

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

≥8

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

其中：

NSUC 是简单用例的数量。

NAUC 是平均用例的数量。

NCUC 是复杂用例的数量。

步骤1.2 – 确定未调整的参与者权重。

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

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

其他参与者，例如通过 GUI 交互的用户，会对用例的复杂性产生重大影响。基于这些差异，您可以将参与者分类为简单、平均和复杂。

步骤1.2.1 – 将参与者分类为简单、平均和复杂，并分配参与者权重，如下表所示：

2

通过 GUI 交互的用户

其中：

3 × NCA

未调整的参与者权重 (UAW)

1 × NSA + 2 × NAA + 3 × NCA

NSA 是简单参与者的数量。

NAA 是平均参与者的数量。

NCA 是复杂参与者的数量。

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

未调整的用例权重 (UUCW) 和未调整的参与者权重 (UAW) 一起给出系统的未调整规模，称为未调整的用例点。

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

4

T9

易于更改

3

T10

6

T12

为第三方提供直接访问

5

F1

熟悉所使用的项目模型

3

步骤 3.4 − 计算所有因素影响力的总和。这得出总环境因素 (EFactor)，如下表所示：

步骤 3.5 − 计算环境因素 (EF) 为：

1.4 + (-0.03 × EFactor)

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

计算调整后的用例点数 (UCP) 为：

UCP = UUCP × TCF × EF

用例点数的优缺点

用例点数的优点

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

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

• 经验丰富的人员进行估算时，基于 UCP 的估算结果与实际结果非常接近。

• UCP 易于使用，无需额外分析。

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

用例点数的缺点

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

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

• 技术和环境因素对 UCP 有很大影响。分配技术和环境因素的值时需要谨慎。

• UCP 有助于初步估算项目总规模，但在指导团队的迭代工作方面作用较小。

估算技术 - 广域德尔菲法

德尔菲法是一种结构化沟通技术，最初开发为一种系统的、交互式的预测方法，它依赖于专家小组。专家们会进行两轮或多轮问卷调查。每轮之后，主持人都会提供专家们上一轮预测的匿名摘要以及他们判断的原因。然后鼓励专家们根据小组其他成员的回复修改他们之前的答案。

人们认为，在这个过程中，答案的范围会缩小，小组会趋向于“正确”的答案。最后，当预定义的停止标准（例如轮数、达成共识和结果稳定性）满足后，该过程就会停止，最后一轮的平均分或中位数分数将决定结果。

德尔菲法于 20 世纪 50 年代至 60 年代在兰德公司开发。

广域德尔菲技术

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

在广域德尔菲技术中，估算团队由项目经理、主持人、专家和开发团队代表组成，团队人数为 3-7 人。共有两次会议：

• 启动会议
• 估算会议

广域德尔菲技术 - 步骤

步骤 1 − 选择估算团队和主持人。

步骤 2 − 主持人主持启动会议，会上向团队介绍问题规范和高级任务列表、任何假设或项目约束条件。团队讨论问题和估算问题（如果有）。他们还决定估算单位。主持人指导整个讨论，监控时间，并在启动会议后准备一份结构化文档，其中包含问题规范、高级任务列表、假设和确定的估算单位。然后，他将此文档的副本转发给下一步。

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

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

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

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

步骤 5.2 − 然后，他在白板上绘制图表。他将每个成员的项目总估算作为 X 绘制在第 1 轮线上，而不公开相应的姓名。估算团队了解估算范围，最初可能范围很大。

步骤 5.3 − 每个团队成员大声朗读他/她制定的详细任务列表，确定所做的任何假设并提出任何问题。任务估算未公开。

组合后的各个详细任务列表构成更完整的任务列表。

步骤 5.4 − 然后，团队讨论他们对已完成的任务、所做的假设和估算问题存在的任何疑问/问题。

步骤 5.5 − 然后，每个团队成员重新审视他/她的任务列表和假设，如有必要进行更改。任务估算也可能需要根据讨论进行调整，记为 +N 小时（更多工作量）和 -N 小时（更少工作量）。

然后，团队成员将任务估算中的更改合并起来，得出项目总估算。

步骤 5.6 − 主持人从所有团队成员那里收集更改后的估算，并将其绘制在第 2 轮线上。

在本轮中，与上一轮相比，范围将更窄，因为它更基于共识。

步骤 5.7 − 然后，团队讨论他们所做的任务修改和假设。

步骤 5.8 − 然后，每个团队成员重新审视他/她的任务列表和假设，如有必要进行更改。任务估算也可能需要根据讨论进行调整。

然后，团队成员再次将任务估算中的更改合并起来，得出项目总估算。

步骤 5.9 − 主持人再次从所有成员那里收集更改后的估算，并将其绘制在第 3 轮线上。

同样，在本轮中，与上一轮相比，范围将更窄。

步骤 5.10 − 重复步骤 5.7、5.8、5.9，直到满足以下标准之一：

• 结果收敛到可接受的窄范围。
• 所有团队成员都不愿更改他们最新的估算。
• 分配的估算会议时间已结束。

步骤 6 − 然后，项目经理收集估算会议的结果。

步骤 6.1 − 他将各个任务列表和相应的估算合并到单个主任务列表中。

步骤 6.2 − 他还将各个假设列表合并。

步骤 6.3 − 然后，他与估算团队一起审查最终任务列表。

广域德尔菲技术的优缺点

优点

• 广域德尔菲技术是一种基于共识的估算技术，用于估算工作量。
• 在估算完成一项任务所需时间时很有用。
• 经验丰富的人员参与，他们分别进行估算，将得出可靠的结果。
• 进行工作的人员正在进行估算，从而得出有效的估算。
• 始终保持匿名性，使每个人都能自信地表达自己的结果。
• 一种非常简单的技术。
• 假设已记录、讨论和商定。

缺点

• 需要管理层的支持。
• 估算结果可能并非管理层想要听到的结果。

估算技术 - 三点估算

三点估算考虑三个值：

• 最乐观估计 (O)，
• 最可能估计 (M)，以及
• 悲观估计（最不可能估计 (L)）。

业界对三点估算和 PERT 存在一些混淆。但是，这些技术是不同的。学习这两种技术时，您会看到它们的区别。此外，在 PERT 技术结束时，会整理并呈现差异。如果您想首先了解它们，可以。

三点估算 (E) 基于简单平均值，遵循三角分布。

E = (O + M + L) / 3

标准差

在三角分布中，

平均值 = (O + M + L) / 3

标准差 = √[((O − E)² + (M − E)² + (L − E)²) / 2]

三点估算步骤

步骤 1 − 得出 WBS。

步骤 2 − 对于每个任务，找到三个值：最乐观估计 (O)、最可能估计 (M) 和悲观估计 (L)。

步骤 3 − 计算三个值的平均值。

平均值 = (O + M + L) / 3

步骤 4 − 计算任务的三点估算。三点估算即平均值。因此，

E = 平均值 = (O + M + L) / 3

步骤 5 − 计算任务的标准差。

标准差 (SD) = √[((O − E)² + (M − E)² + (L - E)²)/2]

步骤 6 − 对 WBS 中的所有任务重复步骤 2、3、4。

步骤 7 − 计算项目的三个点估计。

E（项目）= ∑ E（任务）

步骤 8 − 计算项目的标准差。

SD（项目）= √（∑SD（任务）²）

将项目估算转换为置信水平

这样计算出的三点估算 (E) 和标准差 (SD) 用于将项目估算转换为“置信水平”。

转换基于：

• E ± SD 的置信水平约为 68%。
• E 值 ± 1.645 × SD 的置信水平约为 90%。
• E 值 ± 2 × SD 的置信水平约为 95%。
• E 值 ± 3 × SD 的置信水平约为 99.7%。

通常，所有项目和任务估算都使用 95% 的置信水平，即 E 值 + 2 × SD。

估算技术 - PERT（计划评审技术）

项目评估与评审技术 (PERT) 估算考虑三个值：最乐观估计 (O)、最可能估计 (M) 和悲观估计（最不可能估计 (L)）。行业中关于三点估算和 PERT 存在一些混淆。然而，这两种技术是不同的。在学习这两种技术时，您将看到它们的区别。此外，本章结尾将对这些区别进行整理和呈现。

PERT 基于三个值——最乐观估计 (O)、最可能估计 (M) 和悲观估计（最不可能估计 (L)）。最可能估计的权重是其他两个估计值（乐观和悲观）的 4 倍。

PERT 估计 (E) 基于加权平均值并遵循 beta 分布。

E = (O + 4 × M + L)/6

PERT 经常与关键路径法 (CPM) 一起使用。CPM 指出项目中哪些任务至关重要。如果这些任务延误，项目就会延误。

标准差

标准差 (SD) 衡量估算中的变异性或不确定性。

在 beta 分布中，

均值 = (O + 4 × M + L)/6

标准差 (SD) = (L − O)/6

PERT 估算步骤

步骤 (1) - 制定工作分解结构 (WBS)。

步骤 (2) - 对于每个任务，找到三个值：最乐观估计 (O)、最可能估计 (M) 和悲观估计 (L)。

步骤 (3) - PERT 均值 = (O + 4 × M + L)/6

PERT 均值 = (O + 4 × M + L)/3 (此处原文存在错误，应为/6)

步骤 (4) - 计算任务的标准差。

标准差 (SD) = (L − O)/6

步骤 (6) - 对 WBS 中的所有任务重复步骤 2、3、4。

步骤 (7) - 计算项目的 PERT 估计值。

E（项目）= ∑ E（任务）

步骤 (8) - 计算项目的标准差。

SD (项目) = √ (ΣSD (任务)²)

将项目估算转换为置信水平

由此计算出的 PERT 估计值 (E) 和标准差 (SD) 用于将项目估算转换为置信水平。

转换基于以下原则：

• E ± SD 的置信水平约为 68%。
• E 值 ± 1.645 × SD 的置信水平约为 90%。
• E 值 ± 2 × SD 的置信水平约为 95%。
• E 值 ± 3 × SD 的置信水平约为 99.7%。

通常，所有项目和任务估算都使用 95% 的置信水平，即 E 值 + 2 × SD。

三点估算和 PERT 的区别

以下是三点估算和 PERT 的区别：

估算技术 - 类比估算

类比估算使用类似的过去项目信息来估算当前项目的持续时间或成本，因此得名“类比”。当关于您当前项目的可用信息有限时，您可以使用类比估算。

很多时候，项目经理会被要求为新项目提供成本和持续时间估算，因为管理人员需要决策数据来决定该项目是否值得进行。通常，项目经理或组织中的任何其他人从未做过类似于新项目这样的项目，但管理人员仍然希望获得准确的成本和持续时间估算。

在这种情况下，类比估算是不二之选。它可能并不完美，但它很准确，因为它基于过去的数据。类比估算是易于实施的技术。与初始估算相比，项目成功率可高达 60%。

类比估算 – 定义

类比估算是一种技术，它使用历史数据的参数值作为估算未来活动类似参数的基础。参数示例：范围、成本和持续时间。规模度量示例 - 尺寸、重量和复杂性。

由于项目经理以及可能团队的经验和判断都应用于估算过程，因此它被认为是历史信息和专家判断的结合。

类比估算要求

类比估算需要以下条件：

• 来自过去和正在进行的项目的数据
  • 每位团队成员每周的工作时间
  • 完成项目所涉及的成本
• 与当前项目相近的项目
• 如果当前项目是新的，并且没有类似的过去项目
  • 与当前项目中相似的模块来自过去项目
  • 与当前项目中相似的活动来自过去项目
  • 从这些选定项目中收集数据
• 项目经理和估算团队的参与，以确保对估算进行经验丰富的判断。

类比估算步骤

项目经理和团队必须共同进行类比估算。

• 步骤 1 - 确定当前项目的领域。

• 步骤 2 - 确定当前项目的技术。

• 步骤 3 - 查看组织数据库中是否有类似的项目数据。如果有，请转至步骤 (4)。否则，请转至步骤 (6)。

• 步骤 4 - 将当前项目与已识别的过去项目数据进行比较。

• 步骤 5 - 得出当前项目的持续时间和成本估算。这结束了项目的类比估算。

• 步骤 6 - 查看组织数据库中是否有任何过去的项目具有与当前项目中相似的模块。

• 步骤 7 - 查看组织数据库中是否有任何过去的项目具有与当前项目中相似的活动。

• 步骤 8 - 收集所有这些信息，并利用专家判断来确定当前项目的持续时间和成本估算。

类比估算的优点

• 在项目初期，当对项目的了解非常有限时，类比估算是一种更好的估算方法。

• 该技术简单易行，估算所需时间非常短。

• 由于该技术基于组织过去的项目数据，因此可以预期组织的成功率较高。

• 类比估算也可用于估算单个任务的工作量和持续时间。因此，在 WBS 中估算任务时，可以使用类比。

估算技术 - 工作分解结构 (WBS)

在项目管理和系统工程中，工作分解结构 (WBS) 是将项目分解成较小组成部分的可交付成果导向的分解。WBS 是一个关键的项目可交付成果，它将团队的工作组织成可管理的部分。《项目管理知识体系》(PMBOK) 将 WBS 定义为“项目团队要执行的工作的可交付成果导向的分层分解”。

WBS 元素可以是产品、数据、服务或它们的任何组合。WBS 还提供了详细的成本估算和控制的必要框架，并为进度制定和控制提供了指导。

WBS 的表示

WBS 表示为项目工作活动的层次列表。WBS 有两种格式：

• 大纲视图（缩进格式）
• 树形结构视图（组织结构图）

让我们首先讨论如何使用大纲视图来准备 WBS。

大纲视图

大纲视图是一种非常用户友好的布局。它提供了整个项目的良好视图，并允许轻松修改。它使用数字记录项目的各个阶段。它看起来有点像这样：

• 软件开发

• 范围

  • 确定项目范围
  • 确保项目赞助
  • 定义初步资源
  • 确保核心资源
  • 范围完成

• 分析/软件需求

  • 进行需求分析
  • 起草初步软件规格说明
  • 制定初步预算
  • 与团队一起审查软件规格说明/预算
  • 结合对软件规格说明的反馈
  • 制定交付时间表
  • 获得继续进行的批准（概念、时间表和预算）
  • 确保所需资源
  • 分析完成

• 设计

  • 审查初步软件规格说明
  • 制定功能规格说明
  • 获得继续进行的批准
  • 设计完成

• 开发

  • 审查功能规格说明
  • 确定模块化/分层设计参数
  • 开发代码
  • 开发人员测试（主要调试）
  • 开发完成

• 测试

  • 使用产品规格说明开发单元测试计划
  • 使用产品规格说明开发集成测试计划

• 培训

  • 为最终用户制定培训规范
  • 确定培训交付方法（在线、课堂等）
  • 开发培训材料
  • 完成培训材料
  • 开发培训交付机制
  • 培训材料完成

• 部署

  • 确定最终部署策略
  • 制定部署方法
  • 确保部署资源
  • 培训支持人员
  • 部署软件
  • 部署完成

现在让我们来看看树形结构视图。

树形结构视图

树形结构视图提供了整个项目的非常易于理解的视图。下图显示了树形结构视图的外观。可以使用 MS-Word 中提供的功能轻松绘制这种组织结构图结构。

WBS 的类型

WBS 有两种类型：

• 功能性 WBS - 在功能性 WBS 中，系统是根据要开发的应用程序中的功能来分解的。这对于估算系统规模很有用。

• 活动 WBS - 在活动 WBS 中，系统是根据系统中的活动来分解的。活动进一步分解成任务。这对于估算系统中的工作量和进度很有用。

规模估算

步骤 1 - 从功能性 WBS 开始。

步骤 2 - 考虑叶节点。

步骤 3 - 使用类比法或广域德尔菲法来确定规模估算。

工作量估算

步骤 1 - 使用广域德尔菲技术构建 WBS。我们建议任务不应超过 8 小时。如果任务持续时间较长，请将其拆分。

步骤 2 - 使用广域德尔菲技术或三点估算法来确定任务的工作量估算。

调度

一旦 WBS 准备就绪并且已知规模和工作量估算，您就可以开始安排任务了。

安排任务时，应考虑以下几点：

• 优先级 - 必须在另一个任务之前发生的任务被称为具有另一个任务的优先级。

• 并发 - 并发任务是可以同时（并行）发生的任务。

• 关键路径 - 项目完成日期所依赖的一组特定顺序任务。

  • 所有项目都有关键路径。
  • 加快非关键任务不会直接缩短进度。

关键路径法

关键路径法 (CPM) 是确定和优化关键路径的过程。非关键路径任务可以提前或推迟开始，而不会影响完成日期。

请注意，当您缩短当前关键路径时，关键路径可能会更改为另一个。例如，对于上图中的 WBS，关键路径如下：

由于项目完成日期基于一组顺序任务，因此这些任务称为关键任务。

项目完成日期不基于培训、文档和部署。这些任务称为非关键任务。

任务依赖关系

在进度安排过程中，有时需要考虑任务依赖关系。重要的任务依赖关系包括：

• 结束-开始 (FS)
• 结束-结束 (FF)

结束-开始 (FS)

在结束-开始 (FS) 任务依赖关系中，任务 B 只有在任务 A 完成后才能开始。

结束-结束 (FF)

在结束-结束 (FF) 任务依赖关系中，任务 B 只有在任务 A 完成后才能结束。

甘特图

甘特图是一种条形图，由 Karol Adamiecki 于 1896 年改进，Henry Gantt 于 20 世纪 10 年代独立改进，用于展示项目进度。甘特图说明了项目终端元素和汇总元素的开始和结束日期。

您可以将图 2 中的提纲格式导入 Microsoft Project 以获得甘特图视图。

里程碑

里程碑是进度表中的关键阶段。它们的持续时间为零，用于标志已完成某些任务集。里程碑通常用菱形表示。

例如，在上图的甘特图中，“设计完成”和“开发完成”显示为里程碑，用菱形表示。

里程碑可以与合同条款挂钩。

使用 WBS 进行估算的优势

WBS 在很大程度上简化了项目估算过程。与其他估算技术相比，它具有以下优势：

• 在 WBS 中，识别了项目所有需要完成的工作。因此，通过与项目干系人一起审查 WBS，您不太可能遗漏交付所需项目可交付成果的任何工作。

• WBS 可得出更准确的成本和进度估算。

• 项目经理获得团队参与以最终确定 WBS。团队的参与会在项目中产生热情和责任感。

• WBS 为任务分配提供了基础。因为精确的任务被分配给特定的团队成员，他们将对完成任务负责。

• WBS 能够在任务级别进行监控和控制。这使您可以衡量进度并确保项目按时交付。

估算技术 - 扑克计划

扑克计划估算

扑克计划是一种基于共识的估算技术，主要用于估算 Scrum 中用户故事的工作量或相对大小。

扑克计划结合了三种估算技术：宽带德尔菲技术、类比估算和使用 WBS 进行估算。

扑克计划最初由 James Grenning 于 2002 年定义和命名，后来由 Mike Cohn 在他的著作《敏捷估算与规划》中推广，他的公司对该术语进行了商标注册。

扑克计划估算技术

在扑克计划估算技术中，用户故事的估算值是通过玩扑克计划得出的。整个 Scrum 团队都参与其中，这使得估算快速且可靠。

• 扑克计划使用一副牌进行。由于使用了斐波那契数列，卡片上的数字为 - 1、2、3、5、8、13、21、34 等。这些数字代表“故事点”。每个估算者都有一副牌。当其中一名团队成员举起一张牌时，卡片上的数字应该足够大，以便所有团队成员都能看到。

• 选择一名团队成员作为主持人。主持人阅读正在进行估算的用户故事的描述。如果估算者有任何疑问，产品负责人将解答。

• 每个估算者私下选择一张代表其估算值的牌。在所有估算者都做出选择之前，不显示牌。此时，所有牌同时翻转并举起，以便所有团队成员都能看到每个估算值。

• 在第一轮中，估算值很可能会有所不同。估算值最高和最低的估算者解释他们估算值的原因。需要注意的是，所有讨论都只为了理解，不要把任何事情放在心上。主持人必须确保这一点。

• 团队可以再讨论几分钟关于故事及其估算值。

• 主持人可以记录讨论内容，这在开发特定故事时会有所帮助。讨论结束后，每个估算者通过再次选择一张牌进行重新估算。牌再次保密，直到每个人都估算完毕，然后同时翻转。

重复此过程，直到估算值收敛到一个可以用于该故事的单一估算值。估算轮数因用户故事而异。

扑克计划估算的益处

扑克计划结合了三种估算方法：

专家意见 - 在基于专家意见的估算方法中，会询问专家某事需要多长时间或规模有多大。专家根据其经验、直觉或直觉提供估算值。专家意见估算通常不需要花费太多时间，并且与某些分析方法相比更准确。

类比 - 类比估算使用用户故事的比较。将待估算的用户故事与之前实现的类似用户故事进行比较，由于估算是基于已验证的数据，因此结果准确。

分解 - 分解估算通过将用户故事分解成更小、更容易估算的用户故事来完成。冲刺中包含的用户故事通常在开发时间为 2 到 5 天的范围内。因此，可能需要较长时间的用户故事需要分解成更小的用例。这种方法还确保会有许多可比较的故事。

估算技术 - 测试

测试工作量并非基于任何确定的时间框架。无论测试是否完成，工作都会持续到设定某些预先确定的时间线为止。

这主要是因为传统上，测试工作量估算是开发工作量估算的一部分。只有在使用 WBS 的估算技术（例如宽带德尔菲、三点估算、PERT 和 WBS）的情况下，才能获得测试活动估算值。

如果您已获得功能点 (FP) 的估算值，则根据 Caper Jones 的说法：

测试用例数量 = (功能点数量) × 1.2

获得测试用例数量后，您可以从组织数据库中获取生产力数据，并得出测试所需的工作量。

开发工作量百分比法

所需的测试工作量与开发工作量成正比或百分比关系。可以使用代码行数 (LOC) 或功能点 (FP) 来估算开发工作量。然后，从组织数据库中获取测试工作量的百分比。获得的百分比用于得出测试工作量的估算值。

测试项目估算

现在，一些组织为客户提供独立的验证和确认服务，这意味着项目活动将完全是测试活动。

测试项目估算需要对软件测试生命周期中各种项目的经验。估算测试项目时，请考虑：

• 团队技能
• 领域知识
• 应用程序的复杂性
• 历史数据
• 项目的缺陷周期
• 资源可用性
• 生产力差异
• 系统环境和停机时间

测试估算技术

以下测试估算技术已被证明是准确的，并且被广泛使用：

• PERT 软件测试估算技术
• UCP 方法
• WBS
• 宽带德尔菲技术
• 功能点/测试点分析
• 百分比分配
• 基于经验的测试估算技术

PERT 软件测试估算技术

PERT 软件测试估算技术基于统计方法，其中每个测试任务都被分解成子任务，然后对每个子任务进行三种类型的估算。

该技术使用的公式为：

测试估算 = (O + (4 × M) + E)/6

其中：

O = 乐观估算（最佳情况，没有任何问题，所有条件都最佳）。

M = 最可能估算（最可能的持续时间，可能存在一些问题，但大多数事情都会顺利进行）。

E = 悲观估算（最坏情况，所有事情都出问题）。

该技术的标准差计算如下：

标准差 (SD) = (E − O)/6

用例点法

UCP 方法基于用例，我们计算未调整的参与者权重和未调整的用例权重以确定软件测试估算。

用例是一个文档，它指定不同的用户、系统或其他干系人与相关应用程序交互。它们被称为“参与者”。交互通过称为场景的不同行为或流程来完成某些定义的目标，从而保护所有利益相关者的利益。

步骤 1 - 统计参与者数量。参与者包括正向、负向和例外。

步骤 2 - 计算未调整的参与者权重为

未调整的参与者权重 = 参与者总数

步骤 3 - 统计用例数量。

步骤 4 - 计算未调整的用例权重为

未调整的用例权重 = 用例总数

步骤 5 - 计算未调整的用例点为

未调整的用例点 = (未调整的参与者权重 + 未调整的用例权重)

步骤 6 - 确定技术/环境因素 (TEF)。如果不可用，则取 0.50。

步骤 7 - 计算调整后的用例点为

调整后的用例点 = 未调整的用例点 × [0.65 + (0.01 × TEF)]

步骤 8 - 计算总工作量为

总工作量 = 调整后的用例点 × 2

工作分解结构

步骤 1 - 通过将测试项目分解成小块来创建 WBS。

步骤 2 - 将模块分成子模块。

步骤 3 - 将子模块进一步分解成功能。

步骤 4 - 将功能分解成子功能。

步骤 5 - 检查所有测试需求，确保它们已添加到 WBS 中。

步骤 6 - 确定团队需要完成的任务数量。

步骤 7 - 估算每个任务的工作量。

步骤 8 - 估算每个任务的持续时间。

广域德尔菲技术

在宽带德尔菲方法中，WBS 分发给由 3-7 名成员组成的团队，以对任务进行重新估算。最终估算值是基于团队共识的汇总估算值的结果。

此方法更侧重于经验，而不是任何统计公式。Barry Boehm 推广了这种方法，以强调团队迭代以达成共识，团队在估算测试工作量时设想了问题的不同方面。

功能点/测试点分析

功能点（FP）从用户的角度指示软件应用程序的功能，并用作估算软件项目规模的技术。

在测试中，估算基于需求规格说明书或先前创建的应用程序原型。要计算项目的FP，需要一些主要组件。它们是：

• **未调整的数据功能点** − i）内部文件，ii）外部接口

• **未调整的事务功能点** − i）用户输入，ii）用户输出，iii）用户查询

• **Capers Jones基本公式** −

  测试用例数量 = (功能点数量) × 1.2

• **总实际工作量 (TAE)** −

  (测试用例数量) × (开发工作量百分比 /100)

百分比分布

在这种技术中，软件开发生命周期 (SDLC) 的所有阶段都分配了百分比的工作量。这可以基于来自类似项目的过去数据。例如：

接下来，所有测试阶段的测试工作量百分比将进一步分配给所有测试阶段：

基于经验的测试估算技术

此技术基于类比和专家意见。该技术假设您已经在之前的项目中测试过类似的应用程序，并从这些项目中收集了指标。您还从之前的测试中收集了指标。从非常了解应用程序（以及测试）的主题专家那里获取输入，并使用您收集的指标来确定测试工作量。