24 NESMA 客户应用案例研究

客户应用案例研究

问题描述

这个功能说明是在应用程序开发早期为一个小的客户应用程序制定的。为每位客户维护以下内容：姓名、地址、城市、国家代码、电话和联系人。荷兰客户的商会（CoC）注册号也可以维护。用户希望能够添加、更改和删除数据。当用户想要更改和删除数据时，必须显示当前的客户数据以供验证。用户还希望能够通过以下菜单打印以下报告：
下一页提供了这些报告的草图。国家的名称从一个名为Countries的文件中检索，该文件包含每个国家代码和名称。此文件由其他应用程序维护。

1. 所有客户报表
   此报表包含所有客户以公司排序。不显示荷兰客户的国家。
   

2. 国内客户报表
   本报表包含所有荷兰客户以公司排序。
   

3. 外国客户报表
   此报告包含所有外国客户。用户希望国家出现在列表中每一行的开头。
   

4. 荷兰客户联系人报表
   

5. 按国家分组所有客户的联系人报表
   此报表包含所有客户的电话号码、商会号码和联系人。客户按国家分组。
   
   对于这种应用，必须进行简略功能点分析。

讨论

实体类型Customer可以在应用程序中维护，是一个内部逻辑文件。Country是应用程序只能读取的FPA表。这在FPA表中ELF被视为记录类型。不存在其他FPA表；因此，在这种情况下，FPA表ELF只包含一种记录类型。规范表明可以添加、更改和删除客户数据。这意味着识别了三个外部输入。对外国客户输入商会编号并不起作用。用户没有单独的外部查询需求。当用户更改和删除数据时，出于验证目的而显示当前客户数据不算作单独的外部查询。报告1、2和3一起计为一个外部输出，因为以下内容适用于所有情况：

• 正在报告同一对象（客户）
• 选择标准相同（国家）
• 生产输出产品的过程是相同的（除了选择机制外，不需要额外的过程。）
• 输出产品的逻辑布局（一组数据元素类型及其结构）相同；例如，企业名称+（国家）+电话+（CoC编号）+联系人。括号表示可选性。顺序并不重要。
  在所有情况下都不打印标题是无关紧要的，例如当数据不存在或不需要时；CoC编号或国家名称。毕竟，标题是为输出产品定义的。

尽管报告3中的列顺序不同，但这并不是确定单独外部输出的理由。在这三种情况下，通过标题国家进行直接选择。同样的结果也可以通过填写屏幕实现，在该屏幕中，用户可以获得国家代码作为选择标准。填充屏幕不会被视为单独的外部输入。在FPA中，要填写的数据将被视为外部输出的控制信息，每一条数据将作为数据元素类型包含在分析中。

虽然报表4确实选择了与报表2相同的客户，但逻辑布局不同，因为报表4中的数据元素类型集不同：企业名称+电话+联系人。因此，报告4算作单独的外部输出。

报告5选择与报告3相同的客户。两个报告中的数据元素类型集相同。然而，输出产品的结构不同（数据元素类型分组不同），因为国家只显示一次。因此，逻辑布局不同。因此，报告5被确定为一个单独的外部输出。

根据指南，即使存在外部查询或外部输出，FPA表格ELF也根本没有确定任何事务功能。

解决方案

在简略功能点分析中，逻辑文件被视为低复杂度，事务被视为中复杂度。这导致以下功能规模：

Function	Type	Complexity	Function points	Comments
Customer	ILF	Low	7
FPA-tables-ELF	ELF	Low	5
Add customer	EI	Average	4
Modify customer	EI	Average	4
Delete customer	E1	Average	4
Report 1	EO	Average	5
Report 2	-	-	-	Is the same as report 1 in FPA
Report 3	-	-	-	Is the same as report 1 in FPA
Report 4	EO	Average	5
Report 5	EO	Average	5
MENU	-	-	-	Is not counted
TOTAL			39

这个应用的功能规模是 39 功能点.

原文 NESMA官方示例 第24章 CASE STUDY CUSTOMER APPLICATION