Web服务的FPA计数

[伊利·博阿雷斯库（Ilie Boarescu）]

我写信给您是关于在使用 Web 服务的项目中计算 FPA 时我们应该使用的方法. 也许你可以帮助我一些洞察力.
我将描述两个假设场景以解释情况.

1. 标准方案 – 无 Web 服务

要求:
用户必须能够创建, 查看和编辑产品信息. 在这种情况下，我们会计算:

交易	类型	复杂	功能点
产品	ILF	低	7
创建产品	没有	平均	4
查看产品	情商	平均	4
编辑产品	没有	平均	4
全部的			19

2. 我们的场景 – 必须使用 Web 服务

要求:
用户必须能够创建, 查看和编辑产品信息.
有关产品的数据存储在另一个应用程序中. 要开发的应用程序必须通过网络服务发送和检索数据.

在这种情况下, 我们可以认为存储产品信息的第二个应用程序是第二个用户.
我们为每组跨越应用程序边界的数据计算一个事务.

交易	类型	复杂	功能点
创建产品	没有	平均	4
要求: 创建产品	情商	平均	4
回复: 创建产品	没有	平均	4
查看产品详情	情商	平均	4
要求: 产品详情	情商	平均	4
回复: 产品详情	没有	平均	4
更新产品详情	没有	平均	4
要求: 更新产品详情	情商	平均	4
回复: 更新产品详情	没有	平均	4
全部的			36

这种方法是否正确? 你对这种情况有什么经验?

[马丁·雅各布斯]

你好伊莉,

我处理这样的情况，如下所述.

• 出发点: 内斯马FPA.

标准场景
这里我们要考虑一个系统和一个系统边界. 按照说明算这个.

网页服务
这里我们要考虑两个系统和两个系统边界 (对于此示例，我们不认为可能的 ESB 是介于两者之间的独立系统).

系统:
• 前端 (有限元) 对于最终用户
• 后端 (是) 用于数据存储

FE 向 BE 发送消息并从 BE 接收消息. Web 服务处理消息并且是 FE 的一部分. FE 可以被认为是 BE 的用户 (FE领先).
要计算的系统是 FE, 假设 BE 存在并且不会改变.

基于此，我们可以声明:
• FE 没有 ILF, 他们在 BE.
• Web 服务没有自己的边界.
• 是: 没什么可数的.
• 计数: 只有 FE 包括网络服务.

所以在 FE 中我们正在寻找交易功能. 事务函数是一个独特的, 用户角度的基本功能. 考虑到 BE 和来自 BE 的消息不是基本的. 它们是用户交易的一部分.

所以我们算:
• 创建产品 EI 平均值 4
• 查看产品 EQ 平均值 4
• 编辑产品 EI 平均值 4
全部的 12
在你的 2. 我们的场景, 你也不算第二次申请, 当您将其视为用户时. 所以你认为来自该用户的消息是独一无二的, 初等函数. 根据 Nesma 定义 (例如. 7.1) 然而，它们不是基本的, 所以他们不应该被计算在内.

如果 BE 确实发生了变化, 然后应该计算消息和/或 ILF, 对于这个 BE, 仍然不适合 FE.

希望这可以帮助!

问候,
马丁·雅各布斯
QSM欧洲

[埃德温·哥普]

你好伊莉,

这不是一个容易回答的问题.

首先: 使用 FPA，您可以测量应用程序提供给用户的功能的大小 (Nesma 指南; v2.1; 部分 3.1.2).

现在, 让我们添加第三个场景.
要求:
用户必须能够创建, 查看和编辑产品信息.
有关产品的数据存储在另一个应用程序中, 直接由需要测量的应用程序.

在场景中 1, 你有一个大小为 19 FP.
在场景中 3, 从最终用户的角度来看，该应用程序的功能完全相同 (必须能够创建的用户, 查看和编辑产品信息). 所以, 在这两种情况下，为该用户提供完全相同的功能. 这意味着功能的大小 (从最终用户的角度) 在这两种情况下应该是相同的 (在这种情况下: 19 FP).

现在我的问题是: 什么是, 逻辑上, 你的场景之间的区别 2 和我的场景 3?
提到的 web 服务是第一个应用程序的一部分，能够直接在逻辑文件中存储和编辑数据, 所以根本没有区别. 这意味着第一个应用程序的功能大小仍然是 19 FP, 是否使用网络服务 (网络服务是所需功能的技术实现).
或者, 换种说法, 当您决定使用网络服务来满足这些要求时，最终用户的要求不会改变.

[亚历山大·韦尔默朗]

所以马丁和埃德温,在后端 BE 中开发 Web 服务需要考虑什么?

假设 BE 已经准备好产品表, 但没有提供支持前端的功能的网络服务?
为此，BE 将获得 3 网页服务:
* 创建产品
* 获取产品
* 更新产品

该功能的重要性?

[苏汉南]

你好, 请在场景中告诉我 3, 正在调整大小的应用程序是否拥有产品文件? 然后在这种情况下，我可以看到尺寸相同. 然而, 如果产品文件由被计算的系统之外的应用程序拥有，它将被视为 EIF，因此会更改大小.

我清楚地看到了如何场景 1 和 2 在第一次对话中会导致相同的 19 FP 假设产品文件归正在调整大小的应用程序所有.

现在, 让我们问这个问题, 如果网络服务引用边界外的文件，就像谷歌地图一样, 那么我们是否会保持所有内容相同，除了 ILF 将是 EIF?

[弗兰克Vogelezang]

在场景中 3, 正如埃德温所提议的, 网络服务是要计算的应用程序的一部分. 我对计数没有问题.

亚历山大的回复指的是我经常看到的东西, 那就是后端系统提供网络服务来处理对数据的请求. 当这些服务必须在后端系统中构建时，它们将类似于场景计算 3.

前端系统的功能规模不会改变, 网络服务是否可用. 必须提供给用户的功能是相同的. 当功能可以通过调用现有的 webservices 而不是构建完整的机制来处理后端系统中的数据时，生产力将大不相同.

关于苏的第一句话: 当应用程序能够在后端系统中更改或创建数据时, 产品文件根据定义是一个 ILF, 不管架构师说产品数据属于后端系统.

[作者]

帖子