- Estimation Techniques Tutorial
- Estimation Techniques - Home
- Estimation Techniques - Overview
- Estimation Techniques - FP
- Estimation Techniques - FP Counting
- Estimation Techniques - Use-case
- Estimation Techniques - Delphi
- Estimation Techniques - Three-point
- Estimation Techniques - PERT
- Estimation Techniques - Analogous
- Estimation Techniques - WBS
- Estimation - Planning Poker
- Estimation Techniques - Testing
- Estimation Techniques Resources
- Estimation Techniques - Quick Guide
- Estimation Techniques - Resources
- Estimation Techniques - Discussion
估计技术 - 用例点
用例是用户和系统之间的一系列相关交互,使用户能够实现目标。
用例是捕获系统功能需求的一种方法。系统的用户被称为“参与者”。用例基本上是文本形式。
用例点 – 定义
用例点(UCP)是一种软件估计技术,用于通过用例来衡量软件大小。UCP的概念与FP类似。
项目中 UCP 的数量基于以下因素 -
- 系统中用例的数量和复杂性。
- 系统中参与者的数量和复杂性。
未编写为用例的各种非功能性需求(例如可移植性、性能、可维护性)。
项目将要开发的环境(例如语言、团队的动机等)
使用 UCP 进行估计要求所有用例都以目标和大致相同的级别编写,并提供相同数量的细节。因此,在估计之前,项目团队应确保他们已经以明确的目标和详细程度编写了用例。用例通常在单个会话内完成,在实现目标后,用户可以继续进行其他一些活动。
用例点的历史
用例点估计方法由 Gustav Karner 于 1993 年提出。这项工作后来获得了并入 IBM 的 Rational Software 的许可。
用例点计数过程
用例点计数过程有以下步骤 -
- 计算未调整的 UCP
- 根据技术复杂性进行调整
- 根据环境复杂性进行调整
- 计算调整后的 UCP
步骤 1:计算未调整的用例点。
您首先通过以下步骤计算未调整的用例点 -
- 确定未调整的用例权重
- 确定未调整的演员体重
- 计算未调整的用例点
步骤 1.1 - 确定未调整的用例权重。
步骤 1.1.1 - 查找每个用例中的交易数量。
如果用例是用用户目标级别编写的,则事务相当于用例中的一个步骤。通过计算用例中的步骤来查找事务数。
步骤 1.1.2 - 根据用例中的事务数量将每个用例分类为简单、平均或复杂。另外,分配用例权重,如下表所示 -
用例复杂性 | 交易数量 | 用例权重 |
---|---|---|
简单的 | ≤3 | 5 |
平均的 | 4 至 7 | 10 |
复杂的 | >7 | 15 |
步骤 1.1.3 - 对每个用例重复并获取所有用例权重。未调整用例权重 (UUCW) 是所有用例权重的总和。
步骤 1.1.4 - 使用下表查找未调整用例权重 (UUCW) -
用例复杂性 | 用例权重 | 用例数量 | 产品 |
---|---|---|---|
简单的 | 5 | 国家大学生化委员会 | 5 × NSUC |
平均的 | 10 | NAUC | 10 × NAUC |
复杂的 | 15 | NCUC | 15 × 国立大学 |
未调整用例权重 (UUCW) | 5 × NSUC + 10 × NAUC + 15 × NCUC |
在哪里,
NSUC 是第一。简单用例。
NAUC 是第一。平均用例。
NCUC 是第一。复杂的用例。
步骤 1.2 - 确定未调整的演员体重。
用例中的参与者可能是一个人、另一个程序等。某些参与者(例如具有定义的 API 的系统)具有非常简单的需求,并且只会稍微增加用例的复杂性。
一些参与者,例如通过协议交互的系统有更多的需求,并在一定程度上增加了用例的复杂性。
其他参与者(例如通过 GUI 交互的用户)对用例的复杂性有重大影响。根据这些差异,您可以将参与者分为简单、一般和复杂。
步骤 1.2.1 - 将演员分类为简单、平均和复杂,并分配演员权重,如下表所示 -
参与者复杂性 | 例子 | 演员体重 |
---|---|---|
简单的 | 具有定义的 API 的系统 | 1 |
平均的 | 通过协议进行交互的系统 | 2 |
复杂的 | 用户通过 GUI 进行交互 | 3 |
步骤 1.2.2 - 对每个演员重复并获取所有演员权重。未调整演员权重 (UAW) 是所有演员权重的总和。
步骤1.2.3 - 使用下表查找未调整的演员体重(UAW) -
参与者复杂性 | 演员体重 | 演员人数 | 产品 |
---|---|---|---|
简单的 | 1 | 美国国家安全局 | 1 × 美国国家安全局 |
平均的 | 2 | 北美航空协会 | 2 × NAA |
复杂的 | 3 | 国家计算机协会 | 3×NCA |
未调整的演员体重 (UAW) | 1 × NSA + 2 × NAA + 3 × NCA |
在哪里,
美国国家安全局是第一。简单的演员。
NAA 是第一。平均演员。
NCA 是第一。复杂的演员。
步骤 1.3 - 计算未调整的用例点。
未调整用例权重 (UUCW) 和未调整参与者权重 (UAW) 共同给出了系统的未调整大小,称为未调整用例点。
未调整用例点 (UUCP) = UUCW + UAW
接下来的步骤是调整技术复杂性和环境复杂性的未调整用例点 (UUCP)。
第 2 步:根据技术复杂性进行调整
步骤 2.1 - 考虑导致项目技术复杂性对用例点影响的 13 个因素及其相应的权重,如下表所示 -
因素 | 描述 | 重量 |
---|---|---|
T1 | 分布式系统 | 2.0 |
T2 | 响应时间或吞吐量性能目标 | 1.0 |
T3 | 最终用户效率 | 1.0 |
T4 | 内部处理复杂 | 1.0 |
T5 | 代码必须可重用 | 1.0 |
T6 | 易于安装 | .5 |
T7 | 便于使用 | .5 |
T8 | 便携的 | 2.0 |
T9 | 易于更改 | 1.0 |
T10 | 同时 | 1.0 |
T11 | 包括特殊的安全目标 | 1.0 |
T12 | 为第三方提供直接访问 | 1.0 |
T13 | 需要特殊的用户培训设施 | 1.0 |
其中许多因素代表了项目的非功能性需求。
步骤 2.2 - 对于 13 个因素中的每一个,评估项目并从 0(不相关)到 5(非常重要)进行评分。
步骤 2.3 - 根据因素的影响权重和项目的额定值计算因素的影响:
因素影响力=影响权重×额定值
步骤 (2.4) - 计算所有因素的影响力之和。这给出了总技术系数(TFactor),如下表所示 -
因素 | 描述 | 重量(宽) | 额定值(0至5)(RV) | 冲击力(I = 宽 × RV) |
---|---|---|---|---|
T1 | 分布式系统 | 2.0 | ||
T2 | 响应时间或吞吐量性能目标 | 1.0 | ||
T3 | 最终用户效率 | 1.0 | ||
T4 | 内部处理复杂 | 1.0 | ||
T5 | 代码必须可重用 | 1.0 | ||
T6 | 易于安装 | .5 | ||
T7 | 便于使用 | .5 | ||
T8 | 便携的 | 2.0 | ||
T9 | 易于更改 | 1.0 | ||
T10 | 同时 | 1.0 | ||
T11 | 包括特殊的安全目标 | 1.0 | ||
T12 | 为第三方提供直接访问 | 1.0 | ||
T13 | 需要特殊的用户培训设施 | 1.0 | ||
总技术因素(TFactor) |
步骤 2.5 - 将技术复杂度因子 (TCF) 计算为 -
TCF = 0.6 + (0.01 × T 因子)
第 3 步:根据环境复杂性进行调整
步骤 3.1 - 考虑可能影响项目执行的 8 个环境因素及其相应的权重,如下表所示 -
因素 | 描述 | 重量 |
---|---|---|
F1 | 熟悉所使用的项目模型 | 1.5 |
F2 | 应用经验 | .5 |
F3 | 面向对象的体验 | 1.0 |
F4 | 首席分析师能力 | .5 |
F5 | 动机 | 1.0 |
F6 | 稳定的需求 | 2.0 |
F7 | 兼职人员 | -1.0 |
F8 | 困难的编程语言 | -1.0 |
步骤 3.2 - 对于 8 个因素中的每一个,评估项目并从 0(不相关)到 5(非常重要)进行评分。
步骤 3.3 - 根据因素的影响权重和项目的额定值计算因素的影响:
因素影响力=影响权重×额定值
步骤 3.4 - 计算所有因素影响的总和。这给出了总环境因子(EFactor),如下表所示 -
因素 | 描述 | 重量(宽) | 额定值(0至5)(RV) | 冲击力(I = 宽 × RV) |
---|---|---|---|---|
F1 | 熟悉所使用的项目模型 | 1.5 | ||
F2 | 应用经验 | .5 | ||
F3 | 面向对象的体验 | 1.0 | ||
F4 | 首席分析师能力 | .5 | ||
F5 | 动机 | 1.0 | ||
F6 | 稳定的需求 | 2.0 | ||
F7 | 兼职人员 | -1.0 | ||
F8 | 困难的编程语言 | -1.0 | ||
总环境因子 (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 对于总体项目规模的初步估计很有用,但在推动团队的迭代工作方面却不太有用。